Re: Module proposal: gio and gvfs for gnome 2.22?

["Alex Graveley" <alex beatniksoftware com>]

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 <alexl redhat com> 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.
>
>
>