QRESYNC (was: Re: [POLL] Development guidance)

[Bron Gondwana]

On Tue, Apr 06, 2010 at 12:04:52PM +1000, Robert Mueller wrote:
> > 1) Pro:
> >   * simple to calculate - only updated by cyr_expire
> 
> "simple" seems good :)
> 
> > 1) Con:
> >   * Higher bandwidth use in the "stale client" case.
> 
> If you're not syncing that often, then there's probably enough other
> stuff that needs downloading that it'll swamp the bandwidth anyway.
> 
> > 2) Con:
> >    * Extra bookkeeping - need to update a different record when
> >      removing an expired record.
> >    * Replication implications - cyr_expire and replication is already
> >      going to be tricky - but probably means arbitrary bumping of
> >      modseq on the previous record to guarantee it replicates.  More
> >      spurious modseq bumps.
> 
> These seem a bit scary to me.
> 
> I'd lean towards (1). Simpler to implement, less side effects, less
> chance of odd edge case bugs or replication issues. Slightly more
> bandwidth if you don't sync regularly.

Yeah - I think I've decided on (1) with a syslog every time it gets a
request that triggers a stale client sync - that way sites (like us!) can
see how much they're getting stale syncs, and can decide to either extend
their expiry time or agitate to have (2) implemented!

Bron.