On Tue, 2008-03-25 at 15:46 -0400, Martin Langhoff wrote: > On Tue, Mar 25, 2008 at 10:29 AM, Benjamin M. Schwartz > <[EMAIL PROTECTED]> wrote: > > |> sufficiently generic to encompass multiple versions. I do not fully > > |> grasp the layering between GIO and GVFS. > > Be aware that GIO/GVFS are very high level. In other words, they work > for the Gnome guys because they don't realise that not all the world > links to libgnome ;-)
gio/gvfs doesn't link to anything but glib, dbus and hal on the client side. > zip and tar and rsync and amanda won't work with them. Any modern > program will break trying to use a GIO/GVFS "mount" as their location > of storage. Moderately modern interfaces like mmap - that you need to > work on advanced filehandling, for example in image manipulation > programs - don't work either. GVfs does contain a fuse filesystem implementation that allows posix apps to access the mounted gvfs filesystems, but you're right that the full extent of the posix semantics are not availible in the gio APIs. This is very much by design, as many of the features of posix are just unimplementable on the backends that we want to support. Furthermore, some of the features posix give you to implement certain highlevel operations do not match other backends, even if there are features availible that allow you to implement the desired highlevel operation in some other way. For instance, you want a highlevel "save" operation that implements atomic safe file overwrite (to the extent possible). On posix this is implemented via O_EXCL open of tempfile and then relying on atomic replacement of rename()[1]. However, this just doesn't match how things like ftp and webdav work, but they have other ways to implement this operation. Thus gvfs has a highlevel operation for this with backend-specific implementations. Of course, the goal of gio/gvfs is not to replace all file access. It would make no sense to implement e.g. a database over it, and neighter would it make sense to use for application data files or internal implementation details. Its goal is to be used for what I call "user document" files. This doesn't mean they have to be word processor documents, just the kind of files the user produce and consume during his normal work. If your "modern" application expects to be able to mmap something and get the behaviour you generally expect from mmap that means that then app (by design) can't ever e.g. directly work on a file on an ftp server (in any sane way). Thats a design choice of the app author, although he could of course use gvfs to download the file and then work on it locally. > I expect GVFS to work well for file copy, move and for basic file > viewers, not for a real read/write application. It depends on what you mean by a "real" application of course. The main usecase is for applications that use a load/save document model where the entire document is streamed into memory. > > | * Have some kind of operation that takes a versioned filesystem mount > > | (globally) to a different version. > > Look at git-fuse. fuse is inherently path based too and has no notion of versions, so its not any different from gvfs in this respect. [1] Well, this is a simplification of the posix save code, as its really quite a bit more complicated, but you get the point. _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
