Details vs Match On Args

Kimmo.Hamalainen at Kimmo.Hamalainen at
Fri Jul 8 20:28:38 EST 2005

> -----Original Message-----
> From: dbus-bounces at
> [mailto:dbus-bounces at]On Behalf Of ext John (J5)
> Palmieri
> Sent: 07 July, 2005 22:23
> To: dbus at
> Subject: Details vs Match On Args
> I've been thinking about it a bit and I think we need to do a match on
> arguments instead of details.
> So it has been discussed adding filtering of messages based on
> arguments.  We were either going to go with this or the details patch
> sent awhile ago to deal with signals waking up threads 
> because matching
> was not granular enough [1].
> In my opinion I think we need to match on args to be more flexible and
> also add wildcard matching.  The reason I want to do this is so a
> program can watch for specific names coming on the bus without getting
> deluged by all the names that attach to the bus.  The 
> wildcard matching
> would be for listening for specific namespaces such as 
> listening for all
> names that start with org.freedesktop.* (more compelling would be
> org.gnome.Service.*).  Matching on args also has the 
> advantage of being
> instantly useful without having to think about what data would be
> relevant to place in a arbitrary details field.

In Anders' patch, the daemon sets the detail argument's value for
ServiceOwnerChanged signals. I think this also allows using wildcards
normally when adding match for the signals, since the argument is handled
as any other argument in the match.

I think for other (ordinary, client-made) signals, the detail argument would
normally simply be missing, unless clients decide to use it for something.

The detail argument is only needed for the ServiceOwnerChanged signal,
because services can use naming schemes for filtering client-made signals.
(E.g. using different object path for each signal and using that in the

BR, Kimmo
> I'm going to whip up a patch when I find the time.  What do 
> other people
> think?  
> 1.
> -- 
> John (J5) Palmieri <johnp at>
> -- 
> dbus mailing list
> dbus at

More information about the dbus mailing list