[Bug 19605] Gabble should cache client capabilities

[bugzilla-daemon at freedesktop.org]

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





--- Comment #8 from Senko Rasic <senko at senko.net>  2010-03-09 06:26:30 PST ---
Review up to 1c2bde:

In fd22d6:

* gabble_caps_cache_dup_share() dups the object if not NULL, but
  there's no weak pointer to set the singleton variable back to NULL
  after last unref.
  Elsewhere in the code you use "dup .. use .. unref" pattern, which means
  that unless ref was leaked before, you'll have singleton variable
  pointing to a destroyed object. That is, uless you explicitly
  take care of that somewhere in the initialisation, but I didn't
  see it anywhere.

A few SQLite related comments for 11713f:

* Since we don't care if the cache becomes corrupt due to power/system failure,
  we can safely turn off syncing and on-disk journal. This will lessen the disk
  usage while connecting (when presumably we have the highest number of writes
  to the database - since even a cache hit is a disk write for touching the
  entry). This can be done with PRAGMAs immediately after openning the db.

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


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.