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 > [EMAIL PROTECTED] [EMAIL PROTECTED] --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
