Re: Plans for gnome-vfs replacement

[Johan Dahlin <johan gnome org>]

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