2008/12/23 David Zeuthen <da...@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
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
