dbus - comments requested, here's one
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Jun 25 11:16:18 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.
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
> 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.
More information about the dbus