On Thu, 2007-05-03 at 10:18 -0500, Jerry Haltom 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.)
>
> 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.
Sure, like a pathname or a uri can point to whatever. I guess there is a
slight difference in that a GFile can't be not-well-formed. I.E. if you
got a non-null GFile then it was a valid uri. There is also some level
of uri canonicalization in the GFile (for instance wrt escaping).
The implemenation of GFile is either
GLocalFile: just a pathname
or
GDaemonFile: The uri is turned into a "mount specification", selecting
what gvfs mountpoint to use as root, plus a pathname to use relative to
that mountpoint.
The actual mapping of the "mount specification" to the entity on the
dbus handling such mounts are done when the actual i/o operation
happens. (And at that point you can get a not-mounted error.)
> 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.
Mounting is in almost all cases an explicit operation. I.E. you call
some form of "mount" operation. There are a few cases where we do
support automatic mounting on first i/o, like e.g. mounting computer://,
but that should never happen if the mountpoint ever needs
authentication, can fail, or if its "costly", because applications don't
really expect such behaviour. All mount operations in gvfs are
explicitly async, so that they can do authentication nicely and
integrate well with a gui like gtk+.
The canonical example where automounting causes trouble is listing a
bunch of remote locations in the nautilus sidebar. You don't want to
open 20 authentication dialogs the first time you open the window
because nautilus wanted to stat the locations in the sidebar to get the
icon for them. [Although there are other problems too, see my old mail
about the stateless of gnome-vfs being a problem.]
This might sound a bit tricky for the apps to handle perhaps, but in
practice almost all handling of mounting will be handled by the file
manager and the file selector, similar to how unix mounts are mainly
ignored by apps.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[EMAIL PROTECTED] [EMAIL PROTECTED]
He's a gun-slinging Catholic grifter fleeing from a secret government
programme. She's a virginal French-Canadian research scientist from the wrong
side of the tracks. They fight crime!
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
