Re: D-Bus \approx Mbus

[Vadim Plessky <plessky cnt ru>]

On Monday 03 March 2003 20:39, Havoc Pennington wrote:
|  On Mon, Mar 03, 2003 at 05:13:12PM +0000, Gustavo J. A. M.  Carneiro wrote:
|  >   I don't agree.  This thing is originally meant for multimedia
|  > applications.  But it has messages, addressing, security,
|  > authentication, etc.  You shouldn't disregard it just because of the
|  > word 'Media'.
|  >   I realize you are in a better position to compare, since you
|  > implemented D-Bus while I implemented none.  But saying "not even
|  > remotely" is surely an exaggeration.
|
|  Any IPC mechanism has messages, addressing, security, and
|  authentication. ;-)
|
|  >   At least this thing has an RFC (http://www.ietf.org/rfc/rfc3259.txt),
|  > which makes it stand on its own.  Not that I'm advocating its use, but
|  > it has been thoroughly engineered, it is no longer ad-hoc, unlike
|  > D-Bus.
|
|  D-BUS is very engineered - it's third iteration, we've had DCOP used
|  widely and my earlier prototype FDMB, plus lengthy design discussions
|  with lots of people over a period of many months. Comprehensive specs,
|  automated test coverage, and complete docs are goals, and we've been
|  sticking to those goals pretty well so far. It is 100% API documented
|  and has excellent test suite coverage.

Hi All,

I have posted message on D-Bus on kde-core-devel, and so far I have only 1 
naswer.
I am posting my message here as well, may be someone can provide more details? 
Thanx!

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