+++ This bug was initially created as a clone of Bug #24344 +++ We shouldn't need to disco the Google Talk clients' many many caps bundles: either we already know what they mean, or we don't care about them. We also should cache what the caps hashes we publish mean, to stop us discoing anyone else (possibly even ourself!) with the same hash. Finally, we should remember our past caps hashes, and respond to disco requests for them, both to be a better-behaved client and to work around an iChat bug. A branch fixing this was merged to 0.8 (commit id b64fc7f8); it needs porting to 0.9.
(In reply to comment #0) > Finally, we should remember our past caps hashes, and respond to disco requests for them, both to be a > better-behaved client and to work around an iChat bug. Just curious, what is this iChat bug? One can consider it is better-behaving to reply <item-not-found/> instead of old caps: http://mail.jabber.org/pipermail/standards/2008-May/018712.html http://mail.jabber.org/pipermail/standards/2008-May/018713.html
(In reply to comment #1) > Just curious, what is this iChat bug? If you return an error in response to a caps disco request, it asks you again. > One can consider it is better-behaving to > reply <item-not-found/> instead of old caps: > http://mail.jabber.org/pipermail/standards/2008-May/018712.html > http://mail.jabber.org/pipermail/standards/2008-May/018713.html I don't think that's *better* behaviour, just theoretically acceptable behaviour. Given that it's not exactly hard to remember our past hashes (we want to cache them anyway, so we don't disco other identical Gabbles!), I think responding to older hashes is better behaviour. (Hrm. I wonder what Gabble does if it makes a caps disco request, then the hash changes, then the first one returns...)
(In reply to comment #2) > (Hrm. I wonder what Gabble does if it makes a caps disco request, then the hash > changes, then the first one returns...) Ah, it does the right thing, because of the caps serial number.
Porting the branch to 0.9 wasn't too hard: see my 'improve-caps-cache-0.9' branch.
+ /* FIXME: we should satisfy any waiters for this node now, but I think that + * can wait till 0.9. + */ Please file a bug and reference it in this comment. Otherwise, ++
(In reply to comment #5) > + /* FIXME: we should satisfy any waiters for this node now, but I think that > + * can wait till 0.9. > + */ > > Please file a bug and reference it in this comment. Done (bug #24619) and merged: commit e435bafcde2fb77a43698ae49c316821eb41f571 Author: Will Thompson <will.thompson@collabora.co.uk> Date: Mon Oct 19 14:56:50 2009 +0100 Note bug number for satisfying waiters with our own hash commit 5edd11b52b0d2341ba648cbd87e33cb597bb8164 Merge: 9904163 e435baf Author: Will Thompson <will.thompson@collabora.co.uk> Date: Mon Oct 19 14:57:50 2009 +0100 Merge branch 'improve-caps-cache-0.9' Fixes fd.o bug #24377. Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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.