dbus - comments requested, here's one

[Luke Kenneth Casson Leighton]

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
 hadn't.

 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!]

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