Re: On adding an extension point to GFileInfo

[Alexander Larsson <alexl redhat com>]

On Fri, 2010-01-29 at 17:58 -0500, Adam Plumb wrote:
> I wrote an email to this list in December about this subject, without
> response, so I thought I'd try again and see if anyone bites.
> 
> I'd like to add an extension point to GFileInfo so that modules can
> watch new files as they are created.  My real goal is to create a GIO
> module that acts as a version control daemon, doing VCS lookups on
> files and then applying attributes to the files, or possibly setting
> emblems depending on what the current VCS status is.  The application
> accessing the GFileInfos can apply emblems based on the status
> attributes. Yes, nautilus already has functionality for adding emblems
> from extensions, but Thunar doesn't have such functionality (and won't
> add it, I've tried).
> 
> I'd like to know the maintainers' thoughts on this and how best to
> attack the problem.  I'm happy to mull it over a bit to make sure we
> get this right.

A GFile is not some heavy-weight object that makes sense to track. A
GFile object is equivalent to a "char *path" variable in typical posix
code. Creating, duplicating, passing around, etc of GFile object must
never be do any kind of I/O, and GFile objects are inherently immutable
objetcs.

So, any kind of virtualization like the one you talk about can't be done
by doing anything with the GFile objects.

Instead, the correct place to virtualize i/o is the GVfs interface. All
actual I/O operations pass over this interface. Of course, normally
you'd just use one of the existing implementations, the one for local
files or the gvfs one for remote locations (although there is also e.g.
a http implementation for win32 based on the win32 http support). 

If you don't want to write a completely new VFS then you can extend the
current ones. For GVFS extension means writing a new backend to handle
some new uri scheme. This isn't really what you want. The other
alternative is to extend the local file implementation of e.g.
query_info to pick up new attributes.  This is partially done already
for looking up the gvfs metadata, although its kinda hard for external
modules to hook into this atm.

However, I don't really think that plugging in CVS support at this low
level is a good idea. There is no context for the calls, so its
impossible to keep any state, which means things will be slow (apps
expect the overhead of the i/o calls to be at "a few syscalls" level).
Furthermore, the code has to work in all kinds of contexts (no mainloop,
used in parallel in threads and whatnot) which is hard for non-trivial
implementations.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a suicidal hunchbacked matador with a secret. She's a wealthy goth 
stripper with a birthmark shaped like Liberty's torch. They fight crime!