Re: VFS integration with kernel mounts

[Jerry Haltom <wasabi larvalstage net>]

> The selection of whether to do local or remote i/o is done when
> instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> depending on the uri and the default GVfs instance loaded. However, the
> mapping from URI to what should be done with the file must be done by
> purely in-process non-blocking simple code. Anything complicated (and
> asking hal over dbus for a list of uuids and their paths is very
> complicated) will make the GFile API totally unsuitable for what
> applications normally do with it. (They will block all over the place in
> unexpected places and generally be very slow.)

If this is the case then you are saying that GFiles can simply refer to
non existing resources, and only create IPC when the application
attempts to use them? This seems reasonable.

At what stage is "mounting" considered? Translating a uri to a GFile
doesn't "mount" anything, does it? I would say the HAL communication
would occur when "mounting" the media path. Mounting seems like an
explicitly blocking operation.

> One of the defining aspects of the GFile object is that its a
> light-weight client side only reference to a file. In all aspects an
> abstraction of a filename string.