Concepting a new IPC (was Re: "DBus Embedded" - a clean break)
mardy at users.sourceforge.net
Mon Jan 31 12:16:32 PST 2011
Hello again :-)
I've been convinced that attempting to implement my ideas  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 , 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?
http://blog.mardy.it <- geek in un lingua international!
More information about the dbus