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