Re: EggDBus

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

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

On Tue, 2008-12-23 at 10:12 +0100, Mikkel Kamstrup Erlandsen wrote:
> Hehe, I think it would be stretch to call you that. After all you do
> produce tonnes of code :-)
>
> I a while ago I started hacking on a generic dynamic method invocation
> framework for glib: http://live.gnome.org/MikkelKamstrup/GProxyIdea,
> mailing list thread:
> http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00006.html.
> As of writing I have not got past writing the stub/boilerplate
> GObjects as my spare time is extremely limited. I am most delighted to
> see the progress you have made :-)
>
> My idea was to do something like Java's Proxy class:
> http://java.sun.com/javase/6/docs/api/ which should then be used to
> dynamically build interfaces. Interfaces could fx. be build on the fly
> from a WSDL or something (the main thing missing for this in GLib is
> dynamic method introspection (gobject-introspection lacks the dynamic
> part as far as I know)).
>
>
> Anyway if you read through my GProxyIdea page you should see that you
> might not be the only one being worthy of the "architecture astronaut"
> label :-)

Yeah, I actually looked over those pages before I started coding this.

> One thing though... I am not completely able to grasp the relation of
> EggDBus to GObject-Introspection... I would hope that they could be
> highly integrated so that I could dynamically export an introspectable
> GObjector something like that

Sure, if GObject would gain API to dynamically enumerate methods (in the
same way we already have API like g_signal_list_ids(), g_signal_query()
and g_object_class_list_properties()), it should be possible to write a
function that takes a GObject instance and a creates a proxy that
implements the EggDBusInterface interface. Then you can register that on
the bus and, hey presto, you've exported a GObject on the bus.

Yeah, that was my idea exactly.
 

Of course it wouldn't work for any GObject derived class; I mean, the
object spaces (so to speak) aren't shared between two processes so
wrapping things like GtkBox would never work (unless you do a bijection
between object paths and GObject instances and add things like
factories. But I think in there lies madness.)

Yeah, it would be mostly an exercise in academia too. I am not sure that it will have any cool use case (that is not addressable in any other way) except being cool from a technology-circle-jerk perspective :-)
 

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

 - You'd want something like EggDBusMethodInvocation so you can get
  context about the method invocation, specifically who invoked the
  call (to do security checks etc.). This can also be used to return
  errors. 

  - For some methods, you need to do a lot of IO-ish stuff so you want
  to return the value asynchronously (or specify that you should be
  run in your own thread)

Yes and yes.
 

I'm sure this could easily be done. Anyway, I'm not sure it's generally
useful except for when you use D-Bus to simply export a few remote
control interfaces like e.g. Rhythmbox and friends does.

Right, there really isn't any rocket science involved in writing a dynamic method handling library (or adding it to glib). My plan will probably be to anticipate where GObject-Introspection and EggDBus goes and then see where I can fit in. I already have a bzr branch at lp:gdx. "GLib Dynamic Extensions", but as mentioned earlier this is really just stub classes atm so no need to look at it.

Anyways, I can guarantee very slow progress from my side as I really don't have time to do this :-)
 

It all comes down to how you want to define your D-Bus service.

True. I think I am more in the camp of creating and exporting the interfaces programmatically/dynamically rather than using an IDL+precompiler. As I understand the situation EggDBus does have room for the dynamic approach, but it is just not implemented. If that is correct then I guess I am a happy camper. :-)

-- 
Cheers,
Mikkel