I believe I understand all of your points then. I'm mostly just interested in providing something "useful" to application developers so they can develop applications that are more "useful" to users.
Persistent bookmarks to removable devices. I think a lot of people would like to solve this. The ability for those bookmarks to prompt you to insert the proper media, and if you are unable to, fail gracefully in the application. I think this adds polish. I do recognize of course that what we are talking about are actually just module implementations on the core of GVFS. If *I* wanted to come up with a media://uuid/ schema, I certainly could. Nevertheless, I want to solicit input from the major parties involved. Why doesn't HAL use UUIDs? I'd say probably because up until now there was no abstraction to turn those UUIDs into usefully understandable paths for the user. If you plug in a USB disk and open Nautilus, you see the /media/usbdisk-1 path. They needed to make that look right and didn't want to write a next generation VFS system like you are doing. I could be wrong however. It's worth noting that OS X doesn't mount with UUIDs either. They generate a session-unique value for the mount point, which looks resonable. They encapsulate access to this mount point in an API which understands the uniqueness of a device. I'd like to point out that I'm not advocating UUIDs at all, actually. I'm advocating an abstraction for mounting and browsing removable devices which correspond to kernel VFS paths. It just so happens UUIDs are the first thing that came to mind. The GVFS idea of explicitly "mounting" a resource offers us an extremely good place to add such UI hooks. We've never had these before. There was no real good way to auto mount kernel VFS paths, and allow the UI to request media, so it's never been possible. Are GFile instances extensible? Can a writer of a GVFS module cause custom URI prefixes to return custom GFile implementations? That is really the only thing standing in the way of such an idea being implemented by me or others. To test out my idea, I would need to return a GLocalAndDaemonFile instance which could return NOT_MOUNTED when it wasn't mounted. Can I implement both mounting and local file access through a single GFile subtype? Or do GDaemonFiles *only* support mounting (mounting requiring communication with a daemon of some sort?) I think this is the only area where GVFS design decisions could potentially effect implementing this. As long as you can have a GFile which does both local access and manages mounting, we're good. On Fri, 2007-05-04 at 09:59 +0200, Alexander Larsson wrote: > 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
