dbus first impressions

Tue Sep 7 02:58:05 UTC 2004

Dnia 06-09-2004, pon o godzinie 14:42 -0700, Don Park napisał:
> im a comp sci grad student at portland state univ., and I have an
> interest in distributed computing/message passing. When I first heard
> about dbus I was very curious.
> 
> I feel dbus's role is to provide an RPC mechanism that has a flexable
> access policy mechanism.
> 
> Ive read through the dbus specification at
> http://freedesktop.org/Software/dbus/doc/dbus-specification.html
> and i have a couple questions & comments.

Not all of your questions I'm able to answer, though I'll try to deal
with most of them. If I'm talking crack, correct me please :)

> why have a little endian, big endian flag? wouldnt it be simpler to
> standardize on one bit ordering (like tcp/ip does?)

Because DBUS is explicitly meant for single-machine case, where you
aren't very likely to run into endianness mismatch, and parsing /
constructing simplicity is much more important than genericity

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

No clue here

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

Protocol isn't ASCII-only. That section relates only to auth-protocol,
rest of DBUS is very much unsafe wrt. ASCII. I don't see any way to
"fake" it with telnet

> At first, it looks like a Service name and Message name is all thats
> needed to send a message. In the spec it names service
> org.freenetworks.Peer.Ping, which looks like a good candidate for a
> simple, no-arguments service to try from dbus-send. It looks like Ping is
> the message name and org.freenetworks.Peer is the service name.

s/freenetworks/freedesktop/ to be exact

> "dbus-send org.freenetworks.Peer.Ping" was my intuition (without reading
> the man page) and it fails miserably. Upon reading the dbus-send manpage
> there is a --dest for the service name and the first real parameter is the
> object name. The spec could say more about the object name.

Method recipient is specified in three steps: service path, then object
path, and then interface. You need all of them, although interface name
can be empty[0]. That seems a little bit awkward at first, and is (as I
understand it) optimized for very high load cases[1], like when there
are multiple entities trying to implement given object for service. But
you need to ask Havoc how exactly he sees that used, practice excercised
currently and for any forseeable future is that everyone just ignores
interfaces completely.

> In the dbus-send man page example,
> 
>   dbus-send --dest='org.freedesktop.ExampleService'        \
>                    /org/freedesktop/sample/object/name              \
>                    org.freedesktop.ExampleInterface.ExampleMethod   \
>                    int32:47 string:'hello world' double:65.32
> 
> the service name is already specified - why does the message name have to
> include the service name again?

hmm, it doesn't. Where do you see it repeated? Once it's service name,
and second time it's interface. They are not the same (even if have
identical names, which is not the case in above line)

> Onto the "Message Bus Overview":
> the service field is most confusing. "When the message bus receives a
> message, if the SERVICE field is absent, the message is taken to be a
> standard peer-to-peer message and interpreted by the message bus itself."
> how do i know what messages the 'message bus itself' can handle? is it
> really that command that the message bus itself gives a response to a
> message that every message sent needs this flag?

Remember that DBUS can work in pure point-to-point mode, where there is
no bus inbetween clients.

> "Messages may also be broadcast  by sending them to the special service
> org.freedesktop.DBus.Broadcast. Broadcast messages are sent to all
> applications with message matching rules that match the message."
> 
> i read this to mean the application doing the sending needs to
> know who is in the group. this is impossible most of the time. say there
> is a print queue service and there are multiple print queue monitor apps.
> As the printer driver, I dont know who these apps are.

Hmm? How so? The paragraph you cited states "Broadcast messages are
subject to matching rules set by clients, so that they will be delivered
only to clients that expressed interest in getting given type of
messages". Nothing mandates knowing every possible client by sender
here.

> Rather than having "secondary owners" for a service, the service could
> have multiple simultaneous owners in a publish-subscribe style setup. Then
> as the print driver I could send one message to org.gnome.printqueue and
> dbus could send the message to each person listening to that serice. The
> service would go away when the last subscriber leaves the service.

I'm not totally sure here, but if I understand correctly, that was
decided not worthy doing. Creating some generic policy that would cover
everyone's needs in case of multiple owners is not trivial thing, and
it's not really needed all that often. Leaving it up to ad-hoc schemes
is simply going to work better and is, well, simpler to do.

> what is the reason for base service names? do service names have to be an
> extesion of the base service name (without the : of course)? if not, then
> how are services associated with a base service name? which means, how are
> objects (service names) associated with applications (base service names)?

base service name is guaranteed to be unique for lifespan of bus. It's
akin to "John Smith", where non-base service names are analogous to
"Account Manager"

> in the service activation section, the description file looks like a
> windows .ini file. Why isnt it XML like the other configuration files?

AFAIK to match .desktop files spec.

> Finally, in the "Message Bus Messages", it looks like not enaugh
> information is given to actually call the method. according to dbus-send I
> need to know the service name, the object path, and the method name. What
> I see is the service name, and a function prototype which Im not sure how
> to map into a method name.

That's exactly where messages with no SERVICE field are used. Read your
question regarding that once again :)

> overall i think dbus is a great idea. applications desperately need
> service discovery and neighbor discovery and dbus looks like a promising,
> open-source way to achieve that.

Yes, it is cool indeed[2]

HTH,
Maciej

[0] Strictly speaking, for DCOP compatibiltiy service can also be
omitted if the resulting path is globally unique, although that's
discouraged practice. Hmm, is that still in effect, or was that
possibility removed?
[1] Some would say "overengineered" ;)
[2] I am not dev, merely a user, so have full right to say that :)

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl