|Summary:||[0.9] presences where we're waiting for caps disco said to have no caps|
|Product:||Telepathy||Reporter:||Simon McVittie <smcv>|
|Component:||gabble||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||ASSIGNED ---||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
Description Simon McVittie 2009-10-01 04:52:47 UTC
Consider the following situation: * we receive presence from email@example.com * we don't yet know what foo's capabilities hash means * the disco request is still "in-flight" From inspection of Will's fix for Bug #24250, it seems that GetContactCapabilities (and the equivalent contact attribute) will either return no capabilities at all, or the capabilities derived from an empty set of XMPP caps (e.g. Text); I'm not immediately sure which. In both cases, the contact's caps should be omitted from the returned hash table, to indicate "don't know". If we previously knew some capabilities for the contact, we should probably return those until we get the new ones, if possible?
Comment 1 Simon McVittie 2010-03-04 07:49:32 UTC
Let "basic caps" be the capabilities we assign to every contact, i.e. currently Text. According to testing in my smcv/caps branch, the actual behaviour goes like this: 1. the transition from no presence to available presence causes a transition from unknown caps to basic caps, even before disco#info has completed 2. the transition from one caps hash to another does not cause a transition in ContactCapabilities 3. any disco#info reply causes the ContactCapabilities to be updated, even if we have more disco#info requests in-flight (this can result in caps temporarily switching off!) I think 1. and 3. are bugs, and 2. is correct.