Re: EggDBus
- From: "Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>
- To: "David Zeuthen" <david fubar dk>
- Cc: Dan Winship <danw gnome org>, gtk-devel-list gnome org
- Subject: Re: EggDBus
- Date: Tue, 23 Dec 2008 10:12:53 +0100
2008/12/22 David Zeuthen
<david fubar dk>
On Mon, 2008-12-22 at 11:29 -0500, Dan Winship wrote:
> David Zeuthen wrote:
> > This mail is already too long but there's one more thing.
>
> Yeah. Still digesting. But...
>
> I have not done all that much with D-Bus, but one thing I noticed while
> doing the libsoup 2.4 API rewrite was that, at a very high level, D-Bus
> and XML-RPC are fairly similar, and so it would be neat if the code for
> connecting to or implementing an XML-RPC service with libsoup could use
> the same idioms as the code for connecting to or implementing a D-Bus
> service, rather than presenting more-or-less the same concepts to the
> developer in a completely different way. (And of course, using
> standardized idioms makes it easier to make bindings of the code.)
Oh, it's funny you mention XML-RPC. In a previous life I did a lot of
XML-RPC work including writing my own multi-threaded XML-RPC server in c
++.
FWIW, I've had this item for a while on the TODO list
o Very little of the core functionality is related to D-Bus; would
it be useful to have EggIpcProxy, EggIpcConnection, EggIpcMessage,
EggIpcMethodInvocation GInterfaces that all generated code uses?
Then the existing EggDBus* classes simply implement these interfaces
and the wrappers could be used with, say EggXmlRpc* or EggSoap
implementations too.
Maybe this is just the Architecture Astronaut talking.
However, I made a decision early on to just focus on D-Bus, mostly
because adding another layer of abstraction and indirection would take
my eyes off the ball. And also a concern that it would make it harder to
get buy-in for getting stuff like this into the core library stack (I'm
sometimes accused of being an architecture astronaut :-).
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 :-)
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.
--
Cheers,
Mikkel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]