The file selector and file manager seem like the most pathological users of an IO API. Do we want to expose another largish API because of their requirements? That was what led to gnome-vfs in the first place.
ISVs typically don't use gnome-vfs because it doesn't work x-desktop, and I don't see that changing by pushing it lower in the stack. Maybe removing the added dependency burden will make it more accessible, I dunno. Most apps that I use every day (firefox, thunderbird, OOo, emacs) are unlikely to switch to gio for anything other than opening files via the open dialog. So it's not like pushing gnome-vfs lower is going to suddenly make URLs/paths work the same across the desktop. Are there any stats on gnome-vfs usage? Who uses what? Several of the things you mention (content types, icons, app info) are wrappers for xdg specs and tools. I could see that growing to include volume and file monitoring (one can hope). Would growing xdg APIs be more sustainable than exposing libgio as part of glib? Or do you think the uphill battle with xdg is not worth it? (I'll stop being a cranky old fart now...) -Alex On 9/25/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > On Tue, 2007-09-25 at 05:29 -0700, Alex Graveley wrote: > > Seems like it might be less risky to start in 2.22 by porting all the > > simpler load/save gnome-vfs users to gio first, to flesh out the API. > > > > Replacing an API which has been stable for a few years with an API > > that hasn't seen much review, has had no releases, and has had no > > applications ported to use it scares me. > > > > If load/save is what most people use gnome-vfs for, why not write a > > tiny library with a tiny API that does this well, instead of > > introducing an entire IO framework? Then this library could be > > implemented using gnome-vfs, or gio, or kio, or fuse, or posix, or > > win32 on the backend. (Maybe even made part of fdo.) Keeping the > > API tiny would avoid conflicting with the myriad IO frameworks that > > exist in the high level language platforms. > > While most apps need code only to load and save files the whole desktop > needs more than that. The file manager needs to be able to all sorts of > things, and the file selector (that all apps indirectly pull in) need to > do a lot more than load and save. > > libgio is a (relatively small) API which abstracts out what these apps > needs and implements support for local files. > > I'm sure you can make it smaller, but for every user there would be some > feature missing. > > > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
