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

[Alberto Mardegan]

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?

Ciao,
  Alberto


[0]: http://blog.mardy.it/2011/01/concepting-new-ipc-system.html

-- 
http://blog.mardy.it <- geek in un lingua international!