Re: EggDBus

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2008/12/27 David Zeuthen <david fubar dk>

On Fri, 2008-12-26 at 22:39 +0100, Mikkel Kamstrup Erlandsen wrote:
>
>         So you'd need to tag (using gtk-doc annotations) what methods,
>         properties and signals are to be exported via D-Bus. But it
>         would need
>         to be complicated
>
> The idea was more in the line of how Java does RMI. You define
> interface + impl to export. Consider a Pingable interface (with the
> obvious method) and some instance, myob, of a class MyObject
> implementing Pingable. Then you just call egg_dbus_export (Pingable,
> myob); to put the object on the bus. This still needs a bus name to
> export under of course, but this here is just the basic idea.
>
> The use case I had in mind was xesam-glib where I wanted to integrate
> Xesam services that where not necessarily DBus based. Think Bluetooth,
> Avahi, REST, Soap, etc. All these would be called "transports" in the
> terminology of http://live.gnome.org/MikkelKamstrup/GProxyIdea, in
> which case the above export would become the more general
> g_transport_export(my_trans, Pingable, myob);

Yeah. So you can easily do this with EggDBus right now. Suppose you had
a simple GInterface XesamService that applications offering search
services can implement (I haven't looked closely at Xesam so it's
probably slightly wrong but you get the idea).

You'd use the IDL (presently D-Bus introspection XML) to generate a
GInterface, let's call it XesamServiceAdapter. Then you'd write a
private GObject class that implements this interface, let's call it
_XesamServiceAdapterImpl. The constructor would look like this

 XesamServiceAdapterImpl* _xesam_service_adapter_new (XesamService
*service);

and the class would forward the IPC calls to the passed service. You can
then export that object on the bus

 adapter = _xesam_service_adapter_new (service);
 egg_dbus_connection_register_interface (bus,
                                        "/org/xesam/Application",
                                        adapter);

Yes, this is actually very close to how xesam-glib use dbus-glib right now to abstract DBus out of the core interface. It has in fact proven to be a great boon to do it like this because it allows me to hook tests classes and all sorts of funkyness in instead of the dbus service. I can only advice people keen on unit testing to do the same.
 

I think *something* like this would be nice; perhaps it would be natural
if PackageKit offered a Xesam interface; I don't know enough about Xesam
if something like this makes sense; you and Richard Hughes knows better
than me ;-)

This has crossed my mind and is not unthinkable (on my part at least), but it is a can of worms. When the time is right we can talk it over on the PK or Xesam mailing lists. I am more than willing to engage in that discussion.
 

 

Now, EggDBus right now only does D-Bus. But as noted in the sub-thread
with Dan Winship we *could* make the core bits independent of the
transport. Things like XML-RPC, SOAP and REST (and, ugh, CORBA) probably
makes sense; other (future) transports might make sense too.

Right now, I think whether we end up teaching EggDBus about other IPC
systems is a decision that needs to be made together with the GLib
maintainers. I mean, my proposal is that we get an IPC system in GLib
stack because it turns out a lot of stuff using the GLib stack needs it
(including GTK+).

If it turns out the GLib maintainers don't want an IPC system at all,
I'm all for renaming EggDBus to NGIpc or something else and just have it
be a separate project. But ideally, I think, we want something like a
libgipc-2.0.so library just like we have libgio-2.0.so. Or if the GLib
maintainers decide that they only want the D-Bus bits, then we'd have
libgdbus-2.0.so and other IPC transports would have to do their own
thing (which I don't think is ideal).

So, yeah, to answer your mail we can do all this in, I think, a very
nice way. But right now I'm waiting for feedback from the GLib
maintainers on how to proceed.

Either way, EggDBus is pretty much "done" already (sans a few details)
and will be available in some shape or form soon. And since both the
replacement for HAL (the DeviceKit projects) and the next version of
PolicyKit is going to use it, this library will most likely end up on
all GNOME desktops anyway.

Great. It has pretty much been all good news to me, so thanks for clearing it up for me :-)

-- 
Cheers,
Mikkel