Commit notifications for specs

[Kevin Krammer]

On Thursday 01 May 2008, Emmanuele Bassi wrote:
> 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.

Ah, backends was the name I was looking for.
Pau's suggestion was to look into sharing such backends, which would not 
require any specific technology stack on either side since all operations are 
serialized through some socket anyway.
Your implementation will obviously use shared facilities you provide in your 
libraries such as GvfsBackend, but this is not an archtectural requirement, 
isn't it?

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

If I understand this correctly, this is about in-process plugins, right?

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

Yes, GIO/KIO bridge is written (AFAIK) as a usualy KIO slave (meaning it uses 
kdelibs) and using the GIO API.

Of course it doesn't have to use any KDE code, but I guess this is faster 
right now.

I am currently busy helping in the Akonadi project, but at some point I'd like 
to try a "KDE stack" implementation of the GVFS protocol, mainly for 
accessing GVFS backends from KDE applications but probably also for 
implementing backends.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080501/f28e8b67/attachment.pgp