[Bug 28974] Being able to observe connections

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28974

--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-23 03:58:38 PDT ---
Here's an alternative design with some help from CMs, which I think makes more
sense:

* Connection grows a new property, MatchProperties, analogous to the (unnamed)
immutable properties set on Channel. For simplicity, this is a
Qualified_Property_Value_Map which duplicates the values of the properties.

* MatchProperties has the same semantics as Interfaces: it can change without
notification until CONNECTED, but must "freeze" before
StatusChanged(CONNECTED). All properties with those semantics SHOULD appear in
MatchProperties unless they are obviously useless for matching
(ContactAttributeInterfaces doesn't seem very useful there, for instance).

* For legacy Connection instances, a slow path in TpConnection takes some basic
properties that we know are "freezable" (Interfaces, Status, and a fake
Protocol property derived from the object path) and uses them to fake up a
MatchProperties map.

* MC (really just TpConnection with an appropriate Feature) retrieves
MatchProperties twice: once as soon as possible, to invoke
PreConnectionMonitors, and once after CONNECTED, to invoke ConnectionMonitors.
Any changes between these two retrievals are ignored (they wouldn't be
signalled anyway).

* We still need to be able to match Interfaces somehow, either by saying that
string lists will always match by "pattern is a subset of value", or by
synthesizing a pseudo-property per interface for "this interface exists".
Either way, we can introduce the same mechanism for Channel matching.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.