My comments on D-BUS

[David A. Wheeler]

> > 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.

Okay.  I think it's really important to support short and unsigned short;
they'd be very useful for bridges, for arrays, and for mapping to
the many languages that have short and unsigned short anyway.
And since bindings need to employ type signatures anyway
(to force sent data to be the right type), it doesn't seem to impose
any significant extra effort to do it.

> > > 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.

Oh, whups, we're talking past each other... sorry.
Yes, of course a binding will normally need to copy the data around
so that it's in the "right" format (some CORBA bindings avoid this
at a terrific increase in implementation complexity).
But the native format of a Java string (and many other languages)
is as an array of 16-bit values, so it's just a simple memcopy to
produce a UTF-16.  On the other hand, to create UTF-8, the binding
will have to perform a specific translation.
I'm not hard-over on this; if an unsigned short is supported, then
the people who find this important can do it without making
the rest of the world worry.


> > >>* 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 ;

Okay.  Change STRING description to read like this:
UTF-8 string (must be valid UTF-8, as defined in RFC 3629).
Must be nul terminated, and may not include an embedded nul character.


> 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.

Yes, I completely agree.

--- David A. Wheeler