Bug 28974 - Being able to observe connections
Summary: Being able to observe connections
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2010-07-09 01:10 UTC by Guillaume Desmottes
Modified: 2019-12-03 20:21 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Guillaume Desmottes 2010-07-09 01:10:54 UTC
Here is a crazy idea I had while waiting for the tube this morning. :)

So, with the explosions of crazy Connection interfaces (Location, Gabble plugins implementing various PEP/pubsub related extensions such as bookmarks sharing, etc) we are going to have more and more external applications interested in observing all the connections without caring about channels.

That's the case for exemple of Azimuth. I wrote a simple ConnectionWatcher object to do just that and I think Alban reused it when adding Location support to map-buddy:

Of course we could implement such helper in tp-glib and tp-qt4 but maybe we could do that directly in the spec.

What about allowing clients to observe connections? Azimuth could do something like defining

Observer.ObserverConnectionFilter = [ { 'Connection.Status' : CONNECTED  } ]
Observer.recover = True

we could maybe even define that  { 'Connect.Interfaces' : [ Location ] } means that the connection has to support the Location interface.

Then each time a new connection is connected MC would call on the client something like
ObserveConnection(o: Account, o: Connection, a{sv}: Observer_Info)

This would make writing clients using connection interfaces much easier to write.

So, crack or not?
Comment 1 Guillaume Desmottes 2010-07-09 03:11:40 UTC
Note that one advantage of this approach is to gain the invocation of clients if needed. That would be useful for app such as Azimuth that just need to be started when there are connections connected.
Comment 2 Will Thompson 2010-08-13 08:10:48 UTC
As mentioned in bug 24901, we could use this to ensure mail/voicemail notification UIs are running when needed.
Comment 3 Danielle Madeley 2010-09-23 00:48:39 UTC
Even if we don't add spec to Telepathy, a TpConnectionsMonitor class would be extremely useful. It seems incredibly silly to be copying/rewriting effectively the same code repeatedly for a bunch of small apps that just want to access properties of each Connection.
Comment 4 Simon McVittie 2010-09-23 03:45:04 UTC
This is a good idea in principle but its semantics need some very careful thought.

Most Connection properties are "mutable until CONNECTED", so we can't use filters based on immutable properties.

Most clients only care about CONNECTED connections. Let's call that ConnectionMonitor.

Later, we could have a PreConnectionMonitor that gets unconnected connections, and gets to delay Connect().

Later still, we could have a ConnectionApprover that gets invoked before RequestConnection is called, and can manipulate the Parameters or reject the request with an error. I'm inclined to say YAGNI, though: for the few cases where this would be useful, libmission-control-plugins would probably be more appropriate.
Comment 5 Simon McVittie 2010-09-23 03:45:36 UTC
One way ConnectionObserver could work entirely within MC would be this:

* MC takes the union of the interfaces mentioned in ConnectionObservers' property filters (for instance, if a filter says "…Conn.I.ContactList.CanSet": TRUE, MC would put …Conn.I.ContactList in its set of interesting interfaces)

* whenever a connection becomes CONNECTED, MC fetches the properties of each interesting interface, once, and compares them with the ConnectionObservers' filters

* if a ConnectionObserver uses a property that is mutable after CONNECTED, this is considered an error, but not diagnosed (MC can't know); MC will get an arbitrary early value for it, and filter on that

* as a special case, either we define a pseudo-property "…Conn.I.ContactList/exists" with value TRUE for every interface in Interfaces, or we make the 'as' type pattern-match by "the value is a superset of the pattern from the filter" in general

* whenever a new, previously unknown ConnectionObserver with Recover:TRUE (analogous to the Observer property) appears on the bus, or whenever a recoverable ConnectionObserver crashes, I think MC would have to re-fetch all the properties from all Connections? That's probably better than caching properties whose mutability and usefulness is unknown.

I don't actually think this is the right design: that last point sounds bad.
Comment 6 Simon McVittie 2010-09-23 03:58:38 UTC
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.
Comment 7 GitLab Migration User 2019-12-03 20:21:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/77.

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.