D-BUS design questions [Re: glib in kdesupport: yes or no?]
vplessky at faringosept.ru
Sat Mar 15 18:38:12 GMT 2003
On Monday 10 March 2003 21:22, George Staikos wrote:
| On Monday 10 March 2003 00:50, Havoc Pennington wrote:
| > An important question for KDE is, *if* you were going to use it in
| > addition to or instead of or as a backend for DCOP, how would that
| > migration work, and how would the code be set up. e.g. would you a)
| > swap out the DCOP backend, replacing libICE; b) introduce a new API
| > enough like DCOP to be easy to port to, but different from DCOP; c)
| > keep both DCOP and D-BUS as separate things; or d) some combination of
| > those or something else. We can design D-BUS to make each of these
| > paths easier or harder.
| I spoke with a few KDE developers about this too. I suspect we will
| have to make a bridge between DCOP and D-BUS, keeping DCOP around for
| backward compatibility. If D-BUS lives up to expectations, hopefully it
| would become the new internal API and mechanism for KDE with DCOP apps
| being bridged over. Having two separate, unintegrated RPC mechanisms is a
| bit silly. This is IMHO of course. We have to make sure that D-BUS is at
| least as easy to use for the developer as DCOP is. That means the API must
| easily support calls and signals the way we have them now. Some of this
| will be our own responsibility of course.
I have checked D-BUS specification at:
and have to admit that I failed to understand rationale behind D-BUS design.
"D-BUS is a message bus system, basically a simple way for applications to
talk to one another."
Not going into further details, I'd like to get calrified a few things:
1) do "application" which want to talk to one another run on the same host or
If those apps run on *different* hosts, we effectively need to transfer
messages over network.
What is advantage of bringing up yet-another-specification in this case?
2) are those apps running with the same priority?
I mean: one of apps can be streaming server, which obviously requires higher
priority and should deliver QoS even in heavily-loaded environments.
>From D-Bus Itriduction section:
D-BUS is a system for low-latency, low-overhead, easy to use interprocess
communication (IPC). In more detail:
* D-BUS is low-latency because it is designed to avoid round trips and allow
asynchronous operation, much like the X protocol.
* D-BUS is low-overhead because it uses a binary protocol, and does not have
to convert to and from a text format such as XML. Because D-BUS is intended
for potentially high-resolution same-machine IPC, not primarily for Internet
IPC, this is an interesting optimization.
* D-BUS is easy to use because it works in terms of messages rather than byte
streams, and does not require users to understand any complex concepts such
as a new type system or elaborate APIs. Libraries implementing D-BUS may
choose to abstract messages as "method calls"
What does "low-latency" mean? Would D-Bus deliver Quality of Service?
What kind QoS is warranted?
Besides, "works in terms of messages" and "uses a binary protocol" are
somewhat controversial, IMO.
If you want low-overhead - youshould send byte streams (not byte streams)
I hope Havoc and other developers backing D-Bus can explain a little bit D-Bus
design goals with more details, so that questions above can be answered.
SVG Icons * BlueSphere Icons 0.3.0 released
More information about the kde-core-devel