General question on D-Bus design considerations

[Kees Jongenburger]

Hello Kybernetik,

I am by no means a designer of dbus and think Havoc Pennington's mail
indeed touches some of the core problems but I might have a few more
to add. I believe dbus is very useful and this is partially because of
the relative simplicity of the system while being "complete"
(including security and introspection). The things I am adding bellow
might be "fixable" in dbus so it's hard to say how it would be done if
dbus was created from scratch again.

Terminology used: Event after while , at least for me the "object
path" and "Interface path" and their respective notation are ratter
confusing. I rarely can use dbus-send and manage to call the object I
want in one shot.

The choice to focus on Methods and less on the Message: In dbus one
defines methods /objects that are called. the support for sending
message or structure is quite weak(complex type mappings are ....
complex). If I where to rewrite the dbus I would allow argument that
are passed to methods to be structures (pretty much in the syntax
protocol buffer offers)
http://code.google.com/apis/protocolbuffers/docs/proto.html . When
writing dbus code now a lot of work evolves around converting domain
objects to dbus structures and vise-versa

The messaging paradigm: dbus-daemon is involved as broker in every
message sent when using the system bus. The result is that dbus when
using the system bus can not be used for many of the communication
needed between processes in a normal system(fast event notification or
sending of "mid sized" messages (2MB fails). On embedded system and in
general the overhead of doing this is quite high (context switched ,
parsing and routing of the data serialization). I Believe dbus could
benefit from some optimization (kernel based messaging or point to
point communication between called and service (dbus-daemon acting as
a service broker). I found the following article quite interesting
http://www.zeromq.org/whitepapers:brokerless/noredirect/true
I would try to design the system around "Broker as a Directory Service"

Portability: I was not able to use dbus is some project that would
benefit from it. The main reason is the weak support for dbus on
windows and accessibility of dbus when using  normal (non unix)
sockets in general (due to the security model chosen?). If I where to
design dbus from scratch I might look into supporting Internet sockets
and a different authentication method to allow dbus to be used in more
situations.(Possibly making it a standard of some form). For the same
reason I would try to get decent c++ LGPLV2 bindings


Design problems?: Some might argue I am using dbus the wrong way but I
had problems when using dbus to create a distributed system
(where component can call each other). When implementing a dbus as
service there is only one "main" thread handling input so as long as
this thread is busy no other method can be handled. This gives
different problems that can not really be solved. In other word
recursion is not supported and creating services that handle multiple
clients at the same time is hard(a chat server for example)

Threading: this is mainly due to the dbus-glib stuff but creating
threaded application where different threads use dbus is not possible
without hacking around.

That said and as Havoc mentioned the biggest problem are the current
bindings dbus-glib but when used in the context it currently works as
a low bandwidth system and session bus it's just great!

There are so many IPC/RPC frameworks and none fits all purposes.

Greetings

On Sat, Aug 21, 2010 at 4:31 AM, Kybernetik Kollektiv
<kybernetikkollektiv at googlemail.com> wrote:
> I have a general question for the designers/developers of the D-Bus
> specification: What would you do different compared to the current
> design of D-Bus, if you could or had to start the development of D-Bus
> from scratch today?
>
> Regards
> Patrick
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>