Concepting a new IPC (was Re: "DBus Embedded" - a clean break)

Alberto Mardegan mardy at
Mon Jan 31 12:16:32 PST 2011

Hello again :-)
  I've been convinced that attempting to implement my ideas [0] as
part of D-Bus makes more sense than starting a new project (which was
my initial plan).
Therefore, I'd like to propose a preliminary analysis of what I'd like
to do, and possibly gather some consensus about it.

My goal is to have D-Bus behave similarly to the "T" system I've been
describing in [0], but without putting much stress on the transports,
at least initially; I'd rather want D-Bus messages not to be routed
via the server when they don't need to.

So, my development plan now mainly consists of:

- making the D-Bus daemon create and maintain the shared memory
objects with the list of registered service names and match rules;
then implement direct p2p message passing, via sockets only

- Implement the tag-based message matching

And for the far future, some yet to be refined ideas:
- Make the proxy concept (such as DBusGProxy, GDBusProxy) part of the
core client API, because it can be used to provide further
optimizations to the p2p case

- Investigate the possibility of having the data now provided by the
org.freedesktop.DBus.Introspectable and the
org.freedesktop.DBus.Properties interfaces available on shared memory.

I'll get down into details later on, probably in a blog post. What is
more urgent now for me to understand is what client library I should
be working on. This is a rather fundamental question, because making
the clients communicate in a p2p manner will inevitably lead to heavy
changes on the D-Bus client library.

AFAIK, now most client bindings are implemented on top of libdbus, but
what about GDBus?

Also, what are your views on these proposed changes?



-- <- geek in un lingua international!

More information about the dbus mailing list