Details vs Match On Args

[John (J5) Palmieri]

On Fri, 2005-07-08 at 13:28 +0300, Kimmo.Hamalainen at nokia.com wrote:
> 
> > -----Original Message-----
> > From: dbus-bounces at lists.freedesktop.org
> > [mailto:dbus-bounces at lists.freedesktop.org]On Behalf Of ext John (J5)
> > Palmieri
> > Sent: 07 July, 2005 22:23
> > To: dbus at lists.freedesktop.org
> > 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
> match.)
> 
> BR, Kimmo

However if we check arguments you could just pass it as an argument.  It
is more flexible and I don't see a reason to have both.  In (Sevice|
Name)OwnerChanged you already get the name of the service so why
duplicate it?

-- 
John (J5) Palmieri <johnp at redhat.com>