Details vs Match On Args

[Kimmo.Hamalainen at nokia.com]

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

BR, Kimmo

> 
> -- 
> John (J5) Palmieri <johnp at redhat.com>
> 
> -- 
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>