D-BUS design questions [Re: glib in kdesupport: yes or no?]

[Vadim Plessky]

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.
|

Hi,

I have checked D-BUS specification at:
http://www.freedesktop.org/software/dbus/doc/dbus-specification.html

and have to admit that I failed to understand rationale behind D-BUS design.

http://www.freedesktop.org/software/dbus/  says:

"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 
not?
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:
<quote>
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"
</quote>

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.

-- 

Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net