Re: Plans for gnome-vfs replacement

[Alexander Larsson <alexl redhat com>]

On Mon, 2006-09-18 at 18:47 -0300, Johan Dahlin wrote:
> 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).

The advantage of shipping it inside glib would be that its "easier to
build", as you don't need to build multiple modules. However, I think
this is a false "easy", as the vfs part will have extensive weird
dependencies on things like samba and neon. This means that it gets very
complicated to build glib if you also want a full vfs.

Another advantage is that its easier for separate people to maintain the
backends outside of glib, and that its easier to upgrade them without
having to upgrade glib.

> 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.

Part of the reason things are unclear is that the design is no quite
finished yet. I'll continue working on it, and hopefully produce a bit
more documentation.

> > 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?

I like the java.io.File class which does the pathname abstraction. Win32
has something called "Shell extensions" which are similar to the whole
VFS layer. Other than that there is not a lot of previous art.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a Nobel prize-winning arachnophobic astronaut looking for 'the Big One.' 
She's a ditzy French-Canadian archaeologist from out of town. They fight 
crime!