dbus first impressions

[Don Park]

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.

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

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?

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?

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.

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

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?

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?

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

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.

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

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

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.

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.


Don
-- 
Regime change November 2, 2004.