Re: EggDBus

[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.

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

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

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

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. 

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

For the applications where D-Bus is just used for things like a few
remote control interfaces, defining the interface through the help of
GObject introspection may be useful; it would make it extremely easy to
do just that. And I'd encourage someone looking into making that easier.

But for things like system services (like DeviceKit-disks), you really
want to define the interface using a real IDL and then worry if your
code properly implements the interface.

      David