register object path + introspection

[Rémi Denis-Courmont]

   Hello,

On Fri, 16 Jul 2010 11:29:48 -0400, Havoc Pennington
<havoc.pennington at gmail.com> wrote:
> 2010/7/16 Rémi Denis-Courmont <remi at remlab.net>:
>> I assume "the process" mean the DBus connection.
>> What prevents it from matching the destination (call) or sender (signal,
>> reply)?
> 
> The destination isn't useful because in many proper usages, the
> destination will be the unique bus name, not the well-known one.

I wonder what "proper" means here. In my understanding, method calls should
be sent "to" well-known names directly. In other words, clients should NOT
resolve the well-known names to unique names as this would be obviously
race-prone.

> The sender is always the unique name so that isn't useful either.

So what you mean but are not stating clearly (to me) is that signal
subscriber really need to check both the sender name _and_ the object path.
In other words, an ambiguity occurs if a single process provides two
services with the same interface but different well-known names. Then
signals from those two services would have identical (unique) senders and
interface fields, leaving only the object path to discriminate them.
Correct?

Then given generic interfaces such as D-Bus introspection, any process with
potentially more than one service needs to use name spaces for its object
path. Correct?

So MPRIS sucks but oFono not?

> Really, the bus should strip out the destination field once it routes a
> message, it doesn't just for efficiency reasons, but using this field
> in the receiving process is wrong.

> One advantage of the current design is that it allows tons of objects,
> including "on-demand created" or "virtual" objects, efficiently.

I don't see why the bus would have had to know the objects. The bus could
have the "authenticated" sender headers and left them as is. Then if
services always set the sender name, object path could have been scoped by
bus name. In theory I don't see the problem. Race condition??

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis