Bug 3241

Summary:	python: dbus.Dbus._signal_func should implement new matching algorithm
Product:	dbus	Reporter:	Celso Pinto <cpinto>
Component:	core	Assignee:	John (J5) Palmieri <johnp>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high	CC:	anthony
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Patch for proposed feature

Description Celso Pinto 2005-05-08 05:23:26 UTC

If you add a signal receiver using the following code:
sessionBus.add_signal_receiver(dbus_callback,"MessageReading","org.gnome.evolution.mail.dbus.Signal",None,"/org/gnome/evolution/mail/newmail")

the _signal_func should match signal events the same way as if you had used:
sessionBus.add_signal_receiver(dbus_callback,"MessageReading","org.gnome.evolution.mail.dbus.Signal",":1.12","/org/gnome/evolution/mail/newmail")

An optional parameter should function as a wildcard, therefore the code in
Dbus._signal_func:

if (self._match_rule_to_receivers.has_key(match_rule)):

should be refactored as it doesn't work with wildcards.

Comment 1 Celso Pinto 2005-05-08 16:58:43 UTC

Created attachment 2638 [details] [review]
Patch for proposed feature

This patch enables the use of a wildcard for the service when registering a
signal handler.
If the developer passes None as the service value, when a signal is raised and
we're looking for handlers the service is ignored.

This is most useful, for example, to deal with Evolution notifications since
the service seems to change everytime you start Evolution after shutting it
down.

Comment 2 John (J5) Palmieri 2005-05-23 08:28:32 UTC

Yep, I was going to get around to fixing this.  Will look at the patch and see
if it can be applied.

Comment 3 John (J5) Palmieri 2005-05-23 08:39:18 UTC

At first glance the patch looks good but is applied to the older version of the
bindings.  I am going to port it to the new bindings today.  There is little
chance it will be applied to older bindings.

Comment 4 Anthony Baxter 2005-05-23 10:30:26 UTC

The algorithm is going to take scale very badly as the number of signal handlers
and signals increase. Since the only optional bit is the service, why not simply
try the existing dictionary lookup with and without the ";service=:1.45" bit,
and call all receivers that match either? Or, if other bits are also optional,
do lookups for the combinations that are allowed. Python dictionary comparisions
are *very* fast. Walking through a list and calling custom __cmp__ rules is
going to be very much slower, particularly if the number of signals and handlers
increases.

Comment 5 John (J5) Palmieri 2005-05-23 11:04:35 UTC

I'm just going to hash them with None = '*'.  I don't see any value in making
only one element optional so they all will be.

Comment 6 Celso Pinto 2005-05-23 15:38:17 UTC

(In reply to comment #4)
By all means, optimize or change the patch I proposed :-)
I'm still starting on python development so most of the stuff you mentioned are
way over my head.

Have you committed the changes so I can take a peek?

Comment 7 John (J5) Palmieri 2005-05-23 17:29:25 UTC

I ended up going wild and creating a tree lookup.  It was fun.  Anyway regular
lookup without wildcards should be O(4) or something like that I think worst
case depends on the number of matches you have for the signal.  I don't know I
failed that class ;-) but it is better than liniar for huge sets and only
marginally slower for smaller sets.  Test it out and see what you think.

Comment 8 John (J5) Palmieri 2005-05-23 17:32:07 UTC

*** Bug 3374 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.