Re: Plans for gnome-vfs replacement

[Alexander Larsson <alexl redhat com>]

On Mon, 2006-09-25 at 11:17 +0200, Tim Janik wrote:

> i haven't seen API proposals yet (allthough i haven't managed to read through
> all of this thread yet either ;) so please bear with me if this is covered
> by your ideas already...
> 
> to allow applications to extend on the mechanisms and facilities a new GVFS
> layer will provide, and to support development of experimental backend
> libraries, it could be interesting if the backend plugging API was easy enough
> to be implemented by moderately complex applications.
> 
> so for instance gimp could register an introspection backend that'd allow
> you to list/read //.network/process/localhost/gimp:$PID/procedures/*/info or
> //.network/process/localhost/gimp:$PID/images (provided an instance is running
> and has images loaded).
> 
> i'm not saying that the above gimp example is the most prominent use case,
> or even all that important to implement. it's just there to get the idea
> across, that it'd be nice if apps also could easily register some of their
> own (data production) services as URI/VRI schemes. since a libglibvfs library
> would have to implement neccessary means anyway to communicate with a system/
> user wide daemon to implement your proposal, being able to also use this
> layer as a producer rather than just a consumer for files/data comes as a
> natural extension.

I'm not quite sure what you mean here. Would the gimp application extend
the vfs inside the application, or would it ship with a plugin to the
vfs layer so that other applications can read the gimp state?

I think I see some confusion about the API abstraction layers here.
Consider the vfs as a switch for the filesystem layer. An application
only uses the vfs layer, and is ignorant of what happens underneath it.
This allows us to switch out parts. Any version always have vfs support
to access local files, so apps can use this without enforcing bloat.
Then specially built versions of gtk+ would use a specific
implementation of the vfs allowing applications to seamlessly access
more files. For instance, a win32 build of gtk+ could include a vfs
layer that uses the win32 shell extensions, allowing gtk+ apps to read
files on e.g. bluetooth phones (using the native win32 support for
this).

One of the vfs implementations would be a replacement for the code that
is currently in gnome-vfs. This would be used on most unix-based system,
and it will be pluggable similarly to gnome-vfs so that we can extend
the desktop with new types of file shares or whatever we come up with.
It would be possible for the gimp to extend this vfs implementation, but
not on the glib vfs switch level.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an all-American voodoo filmmaker on the hunt for the last specimen of a 
great and near-mythical creature. She's an elegant communist college professor 
with someone else's memories. They fight crime!