Re: EggDBus

[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);

You'd probably want to hide this behind some nice API like this

 xesam_export_on_session_bus (XesamService *service);
 xesam_export_on_system_bus (XesamService *service);

depending on how you set things up (maybe you need a D-Bus object path..
but ideally you'd hide and/or abstract implementation details like D-Bus
object paths in the Xesam API, I don't know). 

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 ;-)

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.

     David