[Bug 19605] Gabble should cache client capabilities

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-05 08:37:11 PDT ---
(In reply to comment #10)
> So, I don't believe this is a bug.

Me neither.

> > A few SQLite related comments for 11713f:
> 
> Okay, I've added a couple of pragmata that look right.

Looks good to me.

> > * In caps_cache_insert(), instead of ignoring the error of INSERT, we can
> >   use INSERT OR UPDATE ... which will, as a side-effect, save up-to-date
> >   caps for the node, and also touch the timestamp so it won't be reaped
> >   before its time.
> 
> We shouldn't get that far if the entry is already in the hash; that code path
> only occurs when we didn't get a hit from gabble_caps_cache_lookup(), and thus
> discoed the peer. gabble_caps_cache_lookup() does touch the row (UPDATE-ing it,
> setting timestamp = now) when it gets a hit; maybe there's a way to combine
> that with the SELECT?

I have no opinion on this, but it doesn't sound like something that's
incorrect. Senko, do you want to veto this or is it OK to merge as-is?

> I've also added a couple more patches: one fixes the part of the test which
> tries to get a particular entry GCed to actually guarantee that that happens
> (which did involve a whiteboard!), and another removes a useless call to
> sqlite3_column_bytes(). Re-review anyone?

These patches look good to me.

-- 
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.