Re: D-Bus \approx Mbus
- From: Vadim Plessky <plessky cnt ru>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: D-Bus \approx Mbus
- Date: Sun, 16 Mar 2003 14:28:41 +0300
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]