Dbus Inspector & Introspect

Sander Jansen s.jansen at gmail.com
Mon Sep 15 10:39:25 PDT 2008


Thanks. Just one more question, I really hope you don't mind... (yes a
columbo reference :P )
Should I provide match rules for my registered objects (to prevent my
app from waking up unnecessary), or are they typically  only used for
matching signals from remote objects?

Sander


On Mon, Sep 15, 2008 at 11:41 AM, Havoc Pennington <hp at pobox.com> wrote:
> Hi,
>
> On Mon, Sep 15, 2008 at 12:26 PM, Sander Jansen <s.jansen at gmail.com> wrote:
>> This also raised another question I have, should I use the
>> dbus_connection_register_object_path to listen for specific signals
>> from objects not owned by my application or should I use a message
>> filter for that (example, I need to receive signals from
>> "/org/freedesktop/Notifications"). My instinct tells me to use a
>> message filter for that since I do not provide the object so no
>> introspection should take place. Or maybe I can use the
>> register_fallback function for that...
>>
>
> Right, a message filter is right for this; the object path
> registration is to *provide* an object, while for a signal the path
> refers to which object on the other side is sending the signal.
>
> This looks potentially broken in the current code (it looks like
> nobody filters out non-method-calls before dispatching to the
> registered object tree). But that is a bug, if an object receives
> signals from a remote object that happens to have the same path. So if
> it is broken right now, don't rely on it staying that way ;-)
>
> Havoc
>



-- 
"And any fool knows a dog needs a home
A shelter from pigs on the wing"


More information about the dbus mailing list