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. Maybe I'm misunderstanding and that's the intent of libgio? -Alex On 9/24/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > On Mon, 2007-09-24 at 10:37 -0500, Jason D. Clinton wrote: > > On 9/24/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > > I've been working on gvfs and gio for a while, and its starting to reach > > > some minimal level of maturity. > > > > As long as there is consensus on a path from gnome-vfs to gio+gvfs, I > > would like to see this in 2.22. Which module are you proposing? > > Platform? And how long will the transition from gnome-vfs be allowed? > > I'm thinking maybe Desktop for now, since the API is young and we don't > want to freeze it to early. > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
