Commit notifications for specs

[Emmanuele Bassi]

On Thu, 2008-05-01 at 15:21 +0200, Kevin Krammer wrote:
> On Wednesday 30 April 2008, Emmanuele Bassi wrote:
> > On Wed, 2008-04-30 at 19:06 +0200, Pau Garcia i Quiles wrote:
> > > > by the way: GIO implements various fd.o specifications - the
> > > > thumbnailing specification, the trash spec, the shared mime info spec,
> > > > etc. exactly like KIO does.
> > >
> > > KIO and GIO could have shared plugins ("slaves", in KIO slang) but
> > > they do not. That would have been very useful.
> >
> > how would have this been even possible? GIO backends are implemented as
> > GObject using the GModule API, and they are even out of tree from the
> > GIO main library (see the gvfs module inside GNOME's SVN).
> >
> > it would be possible to write a GIO backend using KIO modules, and GIO
> > wouldn't even notice that. the obvious requirement, though, would be
> > that the backend used GObject to be implemented.
> >
> > good luck.
> 
> I have to admit that I only had a quick look at the GIO architecture, but as 
> far as I understand its remote protocol handlers are, like KIO's IO slaves, 
> implemented as out-of-process helpers, thus communicating with the 
> application through a protocol.

those are the backends inside gvfs and yes, they can rely on a low-level
implementation that has nothing to do with GObject; new backends will,
however, inherit from GvfsBackend which is a GObject.

after that, we have gio - which is just the generic high-level API which
will create an "extension" using a module which must return a GType.

hence, yeah: you need GObject to create a GIO backend. you can then use
whatever API to actually implement it - which is how, I guess, the KIO
slave using GIO is written.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net