Details vs Match On Args

[John (J5) Palmieri]

On Mon, 2005-07-11 at 09:18 +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: 08 July, 2005 18:49
> > To: Hamalainen Kimmo (Nokia-M/Helsinki)
> > Cc: dbus at lists.freedesktop.org
> > Subject: RE: Details vs Match On Args
> > 
> > 
> > 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?
> 
> Maybe the existence checking of the detail argument (attribute?) can
> be done more efficiently in the future (instead of the current variable-sized
> array of fields). Even though vectors and other dynamic data structures
> seem to be the Glib way, D-BUS protocol could make some exceptions in the
> future to e.g. allow checking for a valid message be done quickly (instead
> of going along the slowish "Glib type checks" tradition).
> 
> Perhaps arguments should be reserved for non-protocol type of information, due
> to their generic and less-optimised nature.
> 
> But, as D-BUS seems generally not to be the bottleneck, anyway is fine.
> (Generic remark, not specifically related to the issue: It's always the old
> "beauty" of design (or overengineering) vs. efficiency thing... Since D-BUS
> does not use XML, it should always make sure to get the advantage from that
> decision, and not end up implementing the same as XML provides.)

I outlined the performance hit in a previous mail.
http://lists.freedesktop.org/pipermail/dbus/2005-June/002754.html.  If
you are matching on the first arg performance should be roughly the same
since the string has to be demarshaled in either case.  A small hit
would come from checking the signature and demarshling the match rule.
Of course all of this could be optimized if it becomes a problem.

In some cases a match on a large list of arguments would slow things
down but at that point a developer might want to rethink their methods.

In any case I am going to find some time to implement this and then we
can get some real world experience.

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