Re: Plans for gnome-vfs replacement
- From: Tim Janik <timj imendio com>
- To: Alexander Larsson <alexl redhat com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>, Hans Petter Jansson <hpj novell com>
- Subject: Re: Plans for gnome-vfs replacement
- Date: Mon, 25 Sep 2006 11:51:11 +0200 (CEST)
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
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
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
] [Thread Prev