Proposing ObjectManager interface

[David Zeuthen]

Hi,

On Tue, Mar 1, 2011 at 8:59 AM, Will Thompson
<will.thompson at collabora.co.uk> 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 collabora.co.uk> 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 https://bugs.freedesktop.org/show_bug.cgi?id=31818
> 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?

Thanks,
David

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