My comments on D-BUS

[David A. Wheeler]

Thanks so much for the replies!  A few comments...


I said:
>>* I didn't see any reflection capability.

Havoc Pennington replied:
> 
> It's undocumented but exists. You call Introspect() on an object path
> and it returns a big XML string with the object instances at or below
> that path along with the method information.

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?

> Implementing Introspect() is currently left to the bindings though so an
> object implemented in raw libdbus will frequently suck it up and not
> have the method.

Makes sense.

> The choice of xml is because bindings can trivially create and parse
> that, all languages have a few hundred xml parsers available. The other
> reasonable choice would be to use dbus marshaling format, but I think
> that has some disadvantages (among them, you can't save it to a file as
> a nice human-readable IDL).

No problem.  Actually, I think using XML there is an excellent
approach - using dbus marshalling there really doesn't make much sense,
it would create unnecessarily complexity.  Anyone using a reflective
interface can afford to use an XML parser, and XML would be
more flexible anyway.  It may even make reflective interfaces
more likely to be implemented... and implementation simply needs to
respond with a bunch of canned constants for various parameters.

...
>>* Before you set this in stone, I think you NEED to figure
>>   out how to handle sending things over a wider internet.
>>   People don't want to have to deal with 15 different RPC
>>   mechanisms
> 
> 
> People are kind of screwed then, there are already at least 1 million
> afaict. ;-)

Haha!  Quite right.

>>, and I fear that it may have to have fundamental
>>   changes to handle internet-level commo.  Maybe not; the
>>   byte-ordering marker is a clear help, for example... but
>>   until someone's thought it through, it'll be a big question.
> 
> I don't really know how to figure out if fundamental changes are
> required, because I don't know what the use cases would be. I'm very
> uncomfortable trying to architect around hypothetical apps, and I know
> that IPC systems with the internet in mind are either substantially more
> complex than dbus, or really simple because they are just http with a
> pretty bow.

That makes sense.

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.

If someone works out how to bridge DCE, CORBA, and SOAP,
then that would deal with the problem too.


>>* There should be UTF-16 and UTF-32 value support.
> 
> 
> There are some real problems introduced here, pretty well-covered by the
> thread sometime in the last month about implicit type conversion.

Okay, thanks.

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


> Anyhow, it seems like a big can of worms and my leaning is to leave it
> closed... human-readable strings are going to be shortish (a whole book
> is going to transfer and recode pretty quickly) and machine-readable
> strings are going to be XML which is already tons of parsing overhead.

Okay.


>>* There should be a 16-bit signed and unsigned value
>>   (this was in, and then removed in December).  This is
>>   needed to simplify the creation of bridges to other
>>   RPC mechanisms (CORBA, for example, supports both),
>>   and to support arrays of these values.
> 
> 
> I'm not sure this is worth optimizing, since the frequency of "short"
> vs. "int" is incredibly low in most code. There is overhead and
> complexity to each additional type, they make dbus harder to use.
> I can see that it might avoid some hacks for bridges to existing code,
> so maybe it's worthwhile.

They're less common, but they're helpful, and I'm particularly
worried about bridge code.  They're _particularly_ useful for
arrays.  For example, if someone wanted to send
UTF-16 without recoding, an 'array of unsigned short'
makes it fairly easy to do.  Since many programming
languages include these types, there's an advantage in
directly supporting the types actually in the language...
it lets you document what the limits are.

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



>>* Keep type 'Dict'. Dictionaries are _NOT_ the same as
>>   'an array of (String, Value)'; arrays have an ordering...
> Sure, but what you need for this is simply a flag that the array of
> (string, value) has no duplicate strings and has irrelevant order. The
> wire format is going to be array of (string, value), there's no other
> reasonable format. So this flag will either be in the introspection data
> or in the signature somehow.


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



> of course, regexps themselves aren't all that standardized ;-) though I
> guess you have nothing exotic in that one.

Just reference some spec of one of them.
I'd reference the egrep (grep -e) format, e.g., extended regular
expressions, as defined in the Single Unix Specification.



>>* In Signal emission - can you include parameters like a method call?
>>   Why not?  Many languages that originally limited exceptions to
>>   strings (like Python) have switched to permitting more information.
> 
> 
> Yes, signals can have arguments as with any message.

Can you clearly state that in the spec?  That isn't clear to me.



>>* If you change the protocol so that argument signatures are
>>   sent as a separate string, you might want to change some of
>>   the bindings to exploit that...

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

--- David A. Wheeler