roadmap

[Curtis Maloney]

To be up front on my position in this, I agree with keeping it simple, and 
avoiding the "people are listening" callbacks.  If it can be done in a way 
that you don't _have_ to handle it, then great - add the feature.

Whilst I understand Michael's position (I do MCU coding, so I understand how 
precious every byte can be) I believe in the "horses for courses" philosophy.

And honestly, if I were to use DBus on an embedded platform, I'd be wanting 
to plug in a different serialiser - the memory alignment in dbus is great 
for performance, but not so for space efficiency.  Of course, the idea of 
pluggable serialisers is interesting, but that's another story. :)

Havoc Pennington wrote:
> Let's be crystal-clear that dbus not only _is_ but _should be_
> desktop-centric. That is the point of it, and complexifying it to be
> fully generic would make it much worse for desktop purposes. This is
> pointed out in the dbus docs and many times on this list. Please don't
> use dbus unless you're comfortable with this policy.

I think one of the things that has helped DBus come along as quickly as it 
has, and take hold in the industry mind so strongly, is because of this 
clear and narrow focus.

> Maybe matching signals is OK anyway, but generally speaking, dbus is
> designed for a short list of purposes and IMO changing that would be a
> giant mistake.

Of course, there's nothing to stop you writing your own dbus daemon that 
tells services of new listeners...

-- 
Curtis Maloney
cmaloney at cardgate.net