dbus - comments requested, here's one

[Havoc Pennington]

On Tue, 2004-06-29 at 09:53, Tako Schotanus wrote:
> Ok, so in theory it could be done because both systems at a low level
> pass RPC-like messages back and forth.

That's like saying "in theory we could replace the Linux virtual memory
system with the Windows virtual memory system because at a low level
they both manage memory" or "in theory we could replace Java with C
because they both have conditional statements and variables" or "in
theory mutt is the same as Evolution because they both read email" ;-)
You get the idea...

> Is there something you could tell about these requirements? Some
> things that in your opinion set DBus apart from ther rest and that are
> needed to reach the goals that are set for this project? (or is there
> a document already that puts down these requirements?)

There are a lot of list archives and conversations. Among the major
issues are a sufficiently close mapping to DCOP, the message bus (vs.
point-to-point), the precise lifecycle properties of the bus (e.g.
per-session), the systemwide secure message bus with security policies,
ability to handle untrusted clients, design of the API to support
language bindings and main loop integration, the various "best
practices" of current desktop C programming (opaque types, naming
conventions, parallel install, blah blah), lack of controversial
dependencies, I don't know, there are a million things.
There are also nontechnical issues such as control of the spec and
implementation and release cycle sync to support the needs of GNOME,
KDE, and free software OS distributions.

D-BUS is tuned to solve some very specific problems, 1) connecting the
Linux/UNIX kernel/system-daemons to user sessions and 2) desktop IPC for
GNOME and KDE.

> BTW, the reason I myself think we should take a look at this
> technology is because if the new ideas with respect to marshalling. It
> just seems a very complex subject that has many hidden problems that
> we probably haven not yet even thought about. If DBus would stay the
> way it was now message protocol where hardly anything is known about
> the kind of data being send back and forth I would probably not even
> think about it, it's simple enough. But with the marshalling and all
> the language bindings to go with that it does become a totally
> different ballgame, doesn't it? But maybe I'm overestimating the
> complexity of it all?

I personally think that redoing the marshaling code as we've discussed
is a one-week project at most; we have to rework much of these files:

[hp at localhost dbus]$ grep ';' dbus-message.[hc] dbus-marshal.[ch] | wc -l
2903

It's not a heck of a lot of code, and we know more or less exactly how
to go about it.

Havoc