My comments on D-BUS

[Havoc Pennington]

On Thu, 2005-01-20 at 23:33 -0500, David A. Wheeler wrote:
> 
> Okay - sounds like a "documentation bug", which is hardly
> surprising since this is still being built.  Could you document that,
> or at least note that there IS a standard call for it?
> 

Sure, just need enough hours in the day.

> One use case pops out immediately: running a remote X application,
> and having it display on my local display.  I'd like to use
> "ssh -X" to get that running remotely with a secure connection and
> have it work just like a local app, or, if I have a really local
> net with no security concerns (e.g., inside a Beowulf),
> run it straight on IP without encryption.

Right, that's the use case that leads to the TCP support dbus has right
now.

There's already an auth mechanism for this case and the missing piece is
some kind of encryption. If we can figure out how to make ssh do it then
I think we're set.

Or another option is a tunnel-through-X transport.

> > Java is going to have to copy the string anyhow into a native string
> > type...
> 
> Why?  I believe at least Sun's stores strings natively this way.

The string's data block can't point inside the DBusMessage, it has to
make its own copy of the data so the message can be freed.

> While supporting _accepting_ new types adds new code,
> I'll bet that adding support for
> signed and unsigned short is extremely easy :-).

Yes, it is extremely easy. The extra work would all be in bindings, etc.

> >>* Are strings allowed to embed a NUL byte, since their
> >>   length is encoded?
> > 
> > 
> > Nope, strings are human-readable, nul isn't. The length is just there so
> > strings can be quickly skipped over without scanning through them.
> 
> I meant UTF-8; I may have been confusing there.
> Control-A isn't human-readable, and that's a
> legal UTF-8 content value.

Control-A is normally expected in a UTF-8 string though, and most of the
unicode-aware apps will do something sensible with it. nul isn't and
they won't ;-)

> > Yeah, I think there are a large number of improvements and features
> > possible in bindings (that I am conveniently ignoring by punting them
> > all to bindings...)
> 
> Actually, I'd prefer if you DIDN'T do that.
> One problem with CORBA is that the C++ bindings are hard to use.
> Really good bindings are critical to making this easy to use.
> Better to try hard to create good bindings, if you can.

Sure, but I can't do everything at once. I've posted on a couple of
occasions how I think the glib bindings should be done, and written a
lot of the bits myself, but they just need finishing.

In the end for most of the bindings you want someone who knows that
technology to do a binding that will feel "right" in the given language
or API. That was the real headache of CORBA; it invented its whole own
CORBA universe in the API (new types, new malloc/free, new conventions,
etc.) and you had to either leak this universe all over your code, or
write piles of code converting from CORBA-universe to your own. So the
dbus philosophy is that "libdbus" should be concealed entirely by the
binding, and the binding should use native types and conventions.
In other words the binding should be a universe-translation-layer, not
its own universe.

Havoc