Details vs Match On Args
John (J5) Palmieri
johnp at redhat.com
Tue Jul 12 01:24:14 EST 2005
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 .
> > > >
> > > > 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.
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>
More information about the dbus