Introduction to D-BUS

[Thiago Macieira]

Jeroen T. Vermeulen wrote:
>2. Is there any kind of support for failover?  Let's say you have a
> proxy, for an object you looked up using a well-known bus name, and the
> client providing that object dies.  Assume the client restarts (e.g.
> using activation), grabs the same well-known bus name, and once again
> creates that object you had a proxy to.  Is the proxy always dead at
> this stage, or is there a way (for objects that support it, obviously)
> to resume where things left off?

This is a binding-specific question. Some bindings allow you to do that, 
others don't, and others allow you to choose the behaviour. If you want 
to document that, you'll need to verify the info for each binding.

The D-Bus daemon and library couldn't care less about this issue :-)

>3. It's okay for objects to receive method invocation messages, queue
>them, and process them in an order of its own liking, right?

Yes. Needless to say that this behaviour should be documented by whoever 
created the interface.

>4. If it's true that a client can create a proxy on an object behind an
>un-activated service's connection (as Raphaël's Activation Tutorial
> says), why does the D-BUS Tutorial's section on the Python binding say
> that one of the two ways of listening for a signal, which uses a proxy,
> requires the service to be active first?

Because the whole concept of "proxies" is binding-specific. This means the 
behaviour will differ from one to the other. It's the same issue as #2.

>5. Again, if it's true that a service doesn't get activated until a
> method on one of its objects is invoked, how does the caller get to the
> right interface on that object?

I don't see an issue here. If you send a message, either it'll reach 
somewhere, or it won't. If the service name isn't known to the bus 
daemon, it may start a program. If it's known, the message will be 
delivered.

If the message has an object path that corresponds to a valid one, it'll 
be delivered to the object. If the message has an interface that 
corresponds to a valid one, it'll be handled. If the message has the 
function name and parameters that correspond to a valid function, it'll 
be called.

In other words, a method call message will be delivered if and only if the 
whole (service name, object path, interface name, method name, parameter 
type signature) tuple matches a valid destination.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060829/9d3d3d63/attachment.pgp