General questions to DBua

[Robert McQueen]

Matthias Grimm wrote:
> Hi,
> I have tried to find out how DBus works since several days but failed.
> The documentation as well as the howto seems only usefull for people who
> already knows how it works, so I try to ask here.
> 
> 1. Have a program always to know who the recipent of a signal is? DBus
>    was describes as 1-to-1 message bus but I want send a signal to
>    whoever is interested in it (like Battery Low, or Prepare for Sleep).

You do not in general specify the recipient of signal messages - the bus
decides who to forward them to based on match rules. People who are
interested in receiving them would use the AddMatchRule methods to store
match rules in the bus, which tell the bus to forward any matching
signal messages to them.

> 2. related to 1.: Would a client be able to listen for arbitrary signals
>    without knowing from which source they will be emitted? If I have a
>    small Notifier program, that should inform the user about certain
>    events (for example: Only 10 Minutes Battery left) How could I do
>    this? The source for the signal may change depending on architecture
>    or machine model.

Yes, a match rule can specify as few or as many restrictions as you
desire, such as which service, object path, interface or signal name you
wish to receive. You can specify these partially, so request that you
get signal Foo on interface org.freedesktop.Bar signals, regardless of
the sender, or request that get notified of every signal sent by object
/foo/bar on service org.freedesktop.Baz, whatever the interface or
signal name is.

> 3. What is the difference between a "Service" and an "Interface"? It was
>    really confusing for me that in the complete DBus documentation both
>    values are always the same. In my understanding a "Service" is like a
>    office I could go to for certain dutys and the "Interface" tells me
>    what I can do (signals and methods) in this office. Am I right here?

Essentially, yes, although if you add object paths then perhaps each bus
connection would be an office block, its street address would be its bus
names, and the object path would be the floor and number of an office in
the building. The interfaces tell you what you can do in the office.

>    If so: Where are all the Interface definitions stored? I only found
>    DBus.Property and two other in the DBus specification. But if I want
>    to support a certain interface I have to know how it s defined,
>    haven't I?

They are not stored in general. Interfaces are agreed by convention, and
it's certainly useful to have eg the XML to point at and say "this is my
interface". On any object, you may attempt to make a call to the
Introspection interface, and it will return you the interface names,
methods, signals and properties it implements.

> 4. How should I name my services if I didn't own a domain or any other
>    unique network name?

Not sure really.

> 5. Why is the DBus API so complicated? Would have a simple OpenMsgPort(),
>    SendMsg(), ReceiveMsg() and CloseMsgPort() have done it too? Why has
>    everybody fear to use or at least explain the usage of the native
>    DBus API? Actually I won't use any binding to anything I don't need.
>    In other words: Why should I use libdbus-glib if my program doesn't
>    use glib (or any other lib a binding exists for)?

The complication is really quite optional - service names, object paths
and interfaces can all be the same and you can ignore these degrees of
freedom. Indeed, the bindings are a more recent innovation, and original
bus users didn't use them, and would often just have a service
"org.foo.bar" with an object "/org/foo/bar" implementing interface
"org.foo.bar" and just make method calls and signals on these.

You have the option to use bindings to export and make use of objects on
the bus in a way that's more intuitive to your language, and the purpose
of having these defined within the bus protocol is to allow commonality
between bindings - you can implement an object in glib and make use of
it from within Python. If we didn't define stuff like object paths and
interfaces, it would be imposible to convey any more complicated data
models and structures without everyone reinventing the same primitives
(objects, interfaces, etc) again and again.

>    It might be correct that most of the native DBus API is only usefull
>    for bindings, but which functions are this? I really missed a
>    separation of binding-only functions and message bus functions in the
>    docs.

In the API documentation, none of the methods shown pertain to bindings
- these have their own seperate APIs. The low-level stuff you can
ignore, it's relevant to eg how the bus daemon uses the library to
implement itself. The stuff in the public API you can use for setting up
bus connections, requesting names, making messages to call messages and
emit signals, and receive messages.

> That's it for now. I hope the answers will bring me a little bit further.
> Otherwise I will be back soon :-) That's a promise and no thread :-)
> 
>   Best Regards
>    Matthias

Regards,
Rob