Re: Plans for gnome-vfs replacement

[Tim Janik <timj imendio com>]

On Mon, 25 Sep 2006, Alexander Larsson wrote:

> 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 dont know what API you have in mind here, so i'm not sure whether gimp had
to install a plugin here...
but yes, the basic idea is to have the GVFS layer easily allow apps to provide
their own input/output-stream/etc. implementations. so that if gimp starts up,
it can register a GVFS backend object/class to e.g. list it's procedures
and access procedure->blurb as files. yes, that could be used by other
apps to read current gimp state, provided the GVFS daemon is running (since
libgvfs would connect to that daemon anyway if it's up).

> I think I see some confusion about the API abstraction layers here.
> Consider the vfs as a switch for the filesystem layer.

jup, that's exactly what i do. in terms of the unix FS layer, this'd
basically allow every app to provide a FUSE fs for all other apps,
as long as it's running. but in a portable way, since this'll be provided
by GVFS.

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

what level exactly would this be then?

> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson                                            Red Hat, Inc
>                   alexl redhat com    alla lysator liu se

---
ciaoTJ