Re: Relation to gio



On Tue, 2009-01-06 at 22:52 -0200, Vovo ^^ wrote:
> Hello.
> 
> This may be silly but I would appreciate if someone could tell me what
> is the relation between gvfs and gio. I didn't find very usable
> feedback to understand it neither from gio's documentation or gnome's
> website.

GVfs is "just" a set of extensions to GIO, see 

 http://library.gnome.org/devel/gio/unstable/gio-Extension-Points.html

So, basically, GVfs provides a single GIO module (a shared library
loaded into all processes using libgio) with a bunch of different
extensions. Specifically, GVfs extends/replaces GIO functionality in the
following way:

 - Better drive/volume/mount monitoring for UNIX systems; e.g.
   enumeration of drives, volumes and mounts including hotplugging,
   the ability to control disk polling and so on

 - Frameworks for implementing Virtual File Systems and Volume Monitors
   in separate processes (using D-Bus for control and UNIX sockets for
   bulk transfers)

 - A number of virtual file system implementations
   - network file systems: sftp://, ftp://, dav://, davs://, http://
   - "hardware" file systems: gphoto2://, cdda://
   - "misc" file systems: computer:///, trash:///

 - A FUSE bridge such that Virtual File Systems can be accessed
   through ~/.fuse. See http://blog.fubar.dk/?p=104 for more details.

 - A set of command line programs for GIO
   - gvfs-ls, gvfs-copy, gvfs-mount etc.
   - (this really should be in the GIO tree but it's not)

and more. Also, care has been taken not to pollute the processes using
libgio; e.g. deps like libgphoto2 are only used in separate processes.

FWIW, one main reason there's a GIO / GVfs split is to keep the number
of dependencies in libgio to a minimum (mostly) for portability reasons.
E.g. GIO works on Win32, OS X and Unix. The same cannot be said about
GVfs.

Also, right now GVfs offers no API on it's own. At some point that will
change and 3rd parties can develop their own volume monitors and virtual
file systems.  But even when that happens, GVfs is still "just" an
implementation detail of GIO. In other words, applications should never
need to know about GVfs.

Hope this clarifies.

     David




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]