Re: Plans for gnome-vfs replacement

[Tim Janik <timj imendio com>]

On Wed, 20 Sep 2006, Alexander Larsson wrote:

> From just reading your post, without deeper insight into what you mean I
> would be hesitant to add something like that to glib. Its not clear that
> applications need it, and its not clear the the solution we create is
> good enough for the applications that need something like it (in fact, I
> think its likely that such apps want to do their own thing).

> Furthermore, its not a well understood area, and as such I think its a
> bad idea to try to integrate with the basic platform that has guaranteed
> stability and high quality requirements. Having it as a library outside
> glib makes it possible to experiment with and develop the idea.

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.

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

---
ciaoTJ