"DBus Embedded" - a clean break

[Michael Meeks]

On Wed, 2011-01-26 at 09:58 -0500, David Zeuthen wrote:
> I'll repeat what I've said earlier: if you want low latency / high
> bandwidth, the D-Bus protocol greatly limits what you can do

	This is clearly both true, and not that helpful :-) People don't need
something 10,000 times faster, only ~ten - and that is quite achievable
by optimising GDBus IMHO :-) Also, there is a very very substantial cost
in maintainability, readability, debugability and so on cooking up
custom IPC protocols left and right. Surely this is why we try to
standardise a single IPC mechanism, rather than having every different
app use a different mechanism.

	It is somewhat ironic to me (amid all the talk of the joys of cooking
custom protocols), that one of the complicating factors to GDBus's
performance is allowing protocol re-use via telepathy tubes :-) Surely
that is an ideal area to "just create another protocol" if there is any.

> Think about it. Why would you put constraints on your app in the name
> of "we need to use the same IPC everywhere"? Instead, optimize the hot
> spots of your IPC by moving parts of it away from D-Bus to e.g.
> mmap(2) or a socket or whatever. Just like you'd optimize the inner
> loop of a 3D engine by writing the scan converter in assembly

	So - IMHO cooking your own IPC is more analagous to writing your own
language, than switching language choice; and again it is assumed that
there is a need for something 1000x faster, when in many cases there is
not.

> This notion that we absolutely need to fit square pegs in round holes
> need to stop.

	The notion that it is trivial to constantly re-invent IPC mechanisms,
one per task, and that the extra bloat, bugs, reliability, and
discoverability problems etc. are worth having needs killing dead on
sight IMHO :-)

	It is clearly the case, that standardisation helps - a lot; to twist
your analogy: using a different thread on each screw, and making each
nut and bolt fit only each other is not a recipie for good
engineering :-)

	But of course, since I'm not working on optimising the code, I'll shut
up now ;-)

	ATB,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot