dbus first impressions

[Don Park]

On Mon, 6 Sep 2004, Havoc Pennington wrote:

> On Mon, 2004-09-06 at 14:42 -0700, Don Park wrote:
> is a decent overview also. The specification is kind of out of sync with
> the code, unfortunately.

oh no! :) okay I'll keep that in mind.

> Ah, the question *everyone* asks. The normal case here is IPC on a
> single machine, so using network byte order seems a little wasteful.
> If you're already fooling with a binary protocol you may as well
> do byte swapping, since it's a fairly complex undertaking to begin with.

I can understand that. why spend the effort swapping bits if your
archiecture doesn't happen to match the protocol's endianess? its got to
be less work to check the endianness flag of each packet. then again, if
you're talking to the opposite endianness, then you're checking the
little/big flag every time AND doing the swap.

> > the auth mechanism section refers to SASL many times but doesnt come out
> > and say it uses a SASL library. in fact somewhere it says libxml is the
> > only dependency. is an external SASL library used?
> SASL library usage wouldn't belong in the protocol specification, that's
> an implementation detail. We don't use a SASL lib in the current
> implementation but it would be nice to do so.

good point. what I should have said was, does the spec really mean to use
SASL as an authentication mechanism, or is it specifying its own SASL-like
mechanism. Sounds like the answer is the former.

> > The auth section also says "All bytes must be in the ASCII character set."
> > " the protocol is ASCII-only." yet there is the while bit about sending a
> > NULL character. that pretty much eliminates fakeing the protocol with a
> > telnet client, which i thought was one of the advantages of using an ASCII
> > protocol. Why is this initial NULL byte there?
>
> On some old Unices, to send user/group credentials you have to send a
> byte. The nul byte is this byte. I don't remember why it's nul rather
> than 'a' or something, maybe there's no reason.

a dbus client app isn't talking to old unix daemons - you're defining both
ends of the conversation, so why not leave the null byte out if the rest
of the protocol is nice and keyboard-friendly?

> You have:
>  1) services - these are names that are associated with a process
> ...
thanks for the clarification

> > i read this to mean the application doing the sending needs to
> > know who is in the group.
>
> No, the matching rules are kept by the bus, not the app doing the
> sending.

ahhh. Now that makes a lot more sense!

> > Finally, in the "Message Bus Messages", it looks like not enaugh
> > information is given to actually call the method. according to dbus-send I
> Right, this part of the spec has not been updated to reflect the
> addition of object paths. Object paths are sort of redundant in the case

okay that fills in an important gap.

i think im going to have to play with some hello world dbus applications
in order to understand it futher. thanks for your quick and detailed
reply!

don