dbus - comments requested, here's one
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Jun 25 12:54:20 PDT 2004
On Fri, Jun 25, 2004 at 10:13:08AM -0400, Havoc Pennington wrote:
> On Mon, 2004-06-21 at 15:21, Luke Leighton wrote:
> > _why_ are you reinventing the wheel?
> You are presumably making the common claim that "all IPC systems are
> interchangeable" or "there is one universal IPC system suitable for all
> uses," rather than arguing specifically that the tradeoffs in freedce
> are the same as those in D-BUS.
> And I don't believe this claim is true. The reason there are tons of IPC
> systems out there is that there are different tradeoffs to be made.
> Both GNOME and KDE desktop projects have quite a bit of experience with
> various systems (CORBA, ICE, DCOP, X protocol, XML-RPC, SOAP, and more).
CORBA was the direct competitor to DCOM.
ICE i don't know about, other than Gnome uses it.
DCOP i've heard about (KDE uses it)
X protocol i know as a window manager protocol.
XML-RPC is a jumped up wannabe protocol that enabled its author
to get onto the SOAP committee. it doesn't even support the
NULL type. its advantage is that it is simple enough for pretty
much anybody to get to grips with as a "starter" RPC system to
get acquainted with RPC "in general": its shortcomings become very
obvious very quickly and anyone using it in anger will wish they
SOAP is a horrendously overdesigned protocol that quotes the
DCE/RPC opengroup documentation as one of its references. it's
actually very good - _if_ you can get it to work / interoperate -
and you can live with yourself for wasting so much network
bandwidth on wordy taggy exemmelly stuff.
there's also Sun's ONC/RPC [why didn't you consider modifying
and/or implementing ONC/RPC??? it has support for GSS/API,
and is UDP based].
DCE/RPC was the result of The Open Group's call for contributions
when it became clear that several major software vendors were
reinventing RPC "middleware" over and over again, to satisfy
their corporate clients' needs. the core comes from Apollo,
in their NCA (network computing architecture) which became NCS
and then DCE 1.0.
when people began to realise just what DCE/RPC could do, they began
jumping on the bandwagon demanding this feature, that feature:
DCE/RPC has support for 80-bit IBM mainframe floating point,
EBDIC as well as ASCII, dynamic service location, dynamic _transport_
location and usage.
... but the core of what is FreeDCE provides pretty much exactly what
d-bus can do.
oh - also the IDL compiler has support for #include and
typedef'ing and the sorts of things that you would expect c
to provide (and it uses "gcc -E" to do it, i believe)
so it makes for _enormously_ simpler programming.
don't have a UTF-8 string type, and expect one to exist?
create a typedef for it, put it in a file and get everyone
to #include it.
the DCE/RPC "endpoint" mapper - equivalent to portmap from Sun's
ONC/RPC - is just a DCE/RPC client/server application, itself.
the only "special" thing about the DCE/RPC endpoint mapper is that
it _must_ run on a fixed port [in order for applications to be
able to know where to start looking for other services] so on
UDP and TCP that's port 135.
[btw _some_ transports for example Microsoft's MS-RPC which adds "Named
Pipes" as a transport _don't need_ an "endpoint" mapper because the
name _is_ the port, but that's another story]
is this helpful at all?
[btw yes i can do a comparative analysis of DCE/RPC and D-BUS if you like,
but it will take quite some time!]
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:lkcl at lkcl.net"> lkcl at lkcl.net </a> <br />
More information about the dbus