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

 dce/rpc is designed to be fast, flexible, scalable - hence the
 reason why the US government has been trying to bury it for years.

 it can easily be used by an ordinary programmer to turn encryption
 code downloadable off the internet into a brute force cracking engine.
 
 all you need is lots of machines - they don't even have to
 have beowulf, they can just all run DCE/RPC services.


 example of why dce/rpc can be fast: it uses "receiver makes
 right" byte-ordering rules which means that the sender can
 make optimisations based on their word and dword size, and
 if there's a good match, they can just "blat" data out
 over-the-wire, in the full knowledge that the receiver must
 "sort it out".

 the _receiver_ code needs to be flexible, but the _sender_ can
 just say "it's this way round - deal with it".


 if you have "sender makes right" then not only do you have to
 have a round-trip for the sender to determine which byte order
 the receiver will accept...
 
 ... but also no optimisations at the sender end can take
 place because you _might_ have to send in either-endian
 (unless you have a double code paths, one optimised for
 sender's-machine-endian and one _not_ optimised, for
 reverse-sender-endian).


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

 and i believe that dce/rpc is, for the description that your project
 gives ("fast", "message-based" etc) an existing system that is
 already proven, already does what you are attempting to reinvent.
 
 ... why waste it?


 i'm quite happy to write a plugin authentication module for you,
 to do SASL, if that helps [as i mentioned in my initial post,
 all encryption systems have been stripped out of dce 1.1 aka
 freedce but the hooks have been left in]

 if you like i can come up with some digital signing and/or encryption
 scheme that SASL can use.

 i'm also happy to write you a unix-domain-socket transport layer
 plugin, too [again, as i mentioned in my initial post, there is
 evidence of companies like DEC adding their own transport layers
 in e.g. DECNet 3.0 so it's pretty easy to add new transports].

 that'd at least get you started.


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

 so do i.

 l.