Very good read, thanks for a great summary. Alexander Larsson wrote: [snip] > We likely don't want the full gnome/unix vfs implementation in > glib, instead glib will only ship an implementation of the vfs API for > local file access, and one that communicates to the vfs > daemon(s). Then we ship the daemon and the implementations of the > various backends externally.
It might be worth mentioning the advantages & disadvantages of including this directly in glib (as in cvs module/tarball) instead of separating it. I'm all for including it in glib itself, but others might disagree, especially if it's going to be a big (eg, larger than gobject itself). Not sure I completely understand which extension mechanisms that are going to be used. Will GModule be used to implemented the backends/protocols much as it is in gnome-vfs today? It would be helpful to have a diagram or a document describing the components of the proposed API so we can get a complete picture of the flow between application, daemons and applications. > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. You're only mentioning the low-level stream parts here, but is there any previous work of a filesystem/virtual folder API apart from POSIX which could be used as a comparision? Do you know what win32, OS/X, Java, .NET, etc provide in this area? Johan _______________________________________________ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
