[dbus-python] signal filtering bug?

[Simon McVittie]

On Wed, 20 Dec 2006 at 09:50:23 +0100, Wladimir van der Laan wrote:
> Is this a dbus-python specific limitation or one to DBus as a whole?

It's a limitation of the D-Bus specification; before implementing
non-string matching you'd have to design an extension to the spec which
allowed it, and a way to discover whether the running bus daemon
supported your extension (so a new version of a language binding
would work with an old bus daemon, hopefully doing filtering client-side
to emulate the desired behaviour).

The original rationale for argN matching seems to be matching arg0 of
the NameOwnerChanged signal, so that apps can be notified when the
ownership of a name they're interested in changes, while avoiding waking
up the entire desktop whenever an unrelated app connects or disconnects.
(Consider an environment where many apps are running but swapped out,
for instance.) Only string matches are needed for that use case, so
that's all we have.

How important is this behaviour to you? If it doesn't matter that your
app is sometimes spuriously woken up, you could just do the filtering
"client-side" - we could even have an API for this in dbus-python
(perhaps "connect_to_signal(..., arg0=dbus.Int32(147))").

A syntax for the actual match rules which was suggested when this was
first discussed was something like:

	arg0='147',arg0type='i'

You'd also need to specify how each type is represented. For numbers
it's fairly obvious, ASCII decimal. Bytes are probably best handled as
ASCII decimal too. Strings are already supported, object-paths and
signatures could be handled the same as strings, for booleans we could
use 0/1 or t/f or True/False or something.

Double could be tricky (the usual rounding error problems), but I'm not
convinced there's a need to match on those! I suspect container types
are too much work unless someone has a particular need to match them,
but on the other hand, matching variants could well be useful (they'd
have to be something like arg0='i:147', arg0type='v' probably? Or
more usefully, the match rule could be defined to match the outermost
non-variant type, although that would be a slight semantic change).

	Simon