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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
