Re: gnome-keyring should use DBus for discovery

[Alp Toker <alp atoker com>]

Alexander Larsson wrote:
> On Mon, 2007-02-12 at 10:27 +0000, Rob Taylor wrote:
> > Alexander Larsson wrote:
> >
> > > I don't like using dbus-glib-1. That is an ABI unstable library that we
> > > don't want to use at this level of the stack. (It would make all gnome
> > > apps depend on an unstable library...) The way I solve this in gvfs is
> > > to have a copy-paste of the mainloop integration (actually I made my own
> > > version).
> > This raises an interesting point - how can we get dbus-glib to the
> > usablilty it should be? I could make it ABI stable right now, if needed,
> > but there's still an awful lot that should change, especially in terms
> > of being able to demarshal into types of the users choosing. Maybe we
> > could make the next dbus-glib a 1.0 release with proper shlib
> > versioning, and branch for a 2.0 version which makes it more usable.
> >
> > Opinions?
>
> For lowlevel libraries like this we really only need the glib mainloop
> integration. Of course, having that in a library by itself might be a
> bit overkill. Maybe we can put just the glib integration in a static
> library?

Agreed. When I was investigating this issue, I wrote a managed D-Bus to 
gnome-keyring proxy in a couple of hundred lines. It avoided using 
object mapping but instead transformed and proxied messages in a small 
loop and switch statement, taking advantage of the similarity of the 
protocols. Unfortunately, because gnome-keyring uses peer socket 
credentials, it wansn't much use -- the keyring daemon thought all the 
operations were coming from the same application (the proxy service).

But the lesson here is that it's an easy problem to solve and can be 
built on top of the existing library with very little modification.

dbus-sharp has complete support for both tcp and unix method 
peer-to-peer buses with and without glib main loop integration, so we're 
ready to go.