roadmap

Havoc Pennington hp at pobox.com
Mon Aug 11 07:39:18 PDT 2008


Hi,

On Mon, Aug 11, 2008 at 10:16 AM, smog zer <smogzer at gmail.com> wrote:
> Just so that i can understand you better, could you give examples of
> those "life support" services that use libdbus and can't whitstand a
> daemon restart ?

All of them, afaik. HAL, networkmanager, etc. on system bus; and
everything in the user session.

> and why are those services more important than the 2008 - to infinity
> timeline complains that this mailing list will have about the lack of
> support for that kind of trivial features. I find your attitude, of
> rejecting the natural evolution of dbus and sticking to the defective
> design as being the Achiles heel of dbus.

I find your attitude when you've never contributed anything to dbus
and don't know much about it to be ... wrong.

> As for using dbus for starting another ipc that is just an awful
> idea... why not model dbus so that it can be used for everything ?

There are these things called "tradeoffs." For example, the central
bus daemon design of dbus facilitates tracking lifetime of other apps,
and minimizes the number of open sockets ("star" shape of connections
vs. "M*N" connections). However, the central bus daemon costs 2x
performance decrease. That's the correct tradeoff for what dbus is
designed for, but is wrong for other purposes.

There are other IPC systems (hundreds of them) that people already
use. We did not invent dbus because IPC didn't exist, we invented it
because IPC *for these specific purposes we had* didn't exist.

Experienced developers know that sometimes "right tool for the job"
and "keep it simple" are more important than code reuse or "grand
unified system"

> that shows some lack of desire for world domination that is needed in
> the GPL world. Someguy proposed in this mailing list to add shared
> library transport support for dbus and what do you say to him ?
> nothing... he gave up the idea because nobody shows interest... so
> something that could be HUGE like incorporated shmem using dbus types
> was postponed...

I don't remember that post specifically, but if somebody gives up that
easily, they were not going to write a difficult patch (which that
would be) anyway.

And if nobody shows interest, maybe nobody is interested, and it's in
fact *good* not to add a feature if there isn't much interest. We
don't need to bloat up dbus with stuff nobody cares about.

That said, in the future, if people propose something interesting to
you, please show interest. It's an open mailing list and anyone can
contribute to threads.

Havoc


More information about the dbus mailing list