Proposing ObjectManager interface

David Zeuthen zeuthen at
Tue Mar 1 06:06:50 PST 2011


On Tue, Mar 1, 2011 at 8:59 AM, Will Thompson
<will.thompson at> wrote:
> On 01/03/11 12:55, David Zeuthen wrote:
>> Hi,
>> On Tue, Mar 1, 2011 at 6:07 AM, Simon McVittie
>> <simon.mcvittie at> wrote:
>>> On Mon, 28 Feb 2011 at 17:20:45 -0500, David Zeuthen wrote:
>>>>  type='signal',sender=':1.42',pathGlob='/org/app/subtree*'
>>> That's arg0path='/org/app/subtree/', which also matches signals emitted
>>> from /org and /org/app (I don't know why Ryan made it do that - perhaps to
>>> make it symmetric, so it can be an equivalence relation? - but it doesn't seem
>>> likely to be a practical problem).
>> Hmm, that's what I originally thought too when I designed the
>> ObjectManager stuff but I think it's wrong. I mean, the intention is
>> to match any message that concerns a path (not argument) that matches
>> the glob /org/app/subtree* - this doesn't have anything to do with
>> arg0path since the message may not even have any arguments. Right?
> I think my branch on
> makes it possible to do this subtree matching on the path header of the
> message (though I could be wrong, it's been a while).
> The branch also documents why Ryan made it work how it does. The short
> answer is “dconf”.
> It doesn't match on any object paths anywhere in the message: do we
> really want to go down that road? What if a message contains paths
> inside variants inside dicts, should we match those? (I could be
> misunderstanding your mail.)

I want pathPrefix to only match on the objectpath that is in the
*header* of the message [1] - it should _never_ look at the message
body. And I think it would be a bug if argNpath even looked at this
header field. So I think we want something like pathPrefix, yes?


[1] : The spec says the following about this header field: The object
to send a call to, or the object a signal is emitted from. The special
path /org/freedesktop/DBus/Local is reserved; implementations should
not send messages with this path, and the reference implementation of
the bus daemon will disconnect any application that attempts to do so.

More information about the dbus mailing list