Re: VFS integration with kernel mounts

[David Zeuthen <david fubar dk>]

On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote:
> 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.)

But instantiating a GFile itself surely can block? I mean, the
application just don't know in advance what the URI is and if it's an
URI to something that needs to be mounted it will block _anyway_
possibly asking the user for credentials. 

But once the media mounted/connected, it needs to be as efficient as
possible. For example, it's reasonable to assume that some apps (for
better or worse) might want to create GFile objects for hundreds or
maybe thousands of URI's at startup (say, you have a view of hundreds of
photos) so performance needs to be comparable with the usual open(2)
call. Within the same order of magnitude at least. I guess that was your
point? 

I suppose all this is possible by just creating a GLocalRemovableFile
class (that implements GFile and possibly derives from GLocalFile). This
would have to be smart about figuring out whether the media is available
or not, e.g. it could utilize a temporary cache file (shared by all
users of the gio API) in your home directory that maps the media UUID to
the mount point. So it would only poke HAL the very first time, in a
session, it tries an URI from a given piece of media. It would also use
inotify etc. to watch that cache file so you wouldn't even need to do
open/read/close the file every time.

If the media is not available, NOT_MOUNTED is returned and the file
chooser / file manager / app is free to do what it wants, e.g. put up a
dialog (preferably using common shared utility API). Just like
GDaemonFile I suppose.

If the media is available, we have the local mount point
(e.g. /media/usbdisk) and use this for all the file operations.

The aliasing problem aside, is there anything wrong with this approach?

      David