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: https://garage.maemo.org/plugins/ggit/browse.php/?p=azimuth;a=blob;f=src/connection-watcher.c;h=04f4b875a46cf71d9f5b6508785fec165232bde7;hb=HEAD 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?
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.
As mentioned in bug 24901, we could use this to ensure mail/voicemail notification UIs are running when needed.
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.
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.
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.
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.
-- 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.