Syncing strategy

[Daniel Pittman]

On Wed, Dec 8, 2010 at 20:22, Sebastian Spaeth <Sebastian at sspaeth.de> wrote:

> I am looking into our syncing algorithm and plan to provide patches that
> document it better, and also tweaks the logic (still need my test suite
> before that).
>
> I have a couple of questions about our policy in certain situations:

[...]

> Finally, our current strategy is to go though all folders and syncing
> local changes to the remote server. After finishing we go through all
> folders again and sync remote changes to the local side. I don't know if
> plenty of IMAP "SELECT" statements hurt us performance-wise.

It will, on some servers, where there a select (which is, in essence,
a read/write lock on the folder) costs a second or two of processing
time without competitive load.  (OTOH, you could probably EXAMINE for
the server -> local phase, which is a read-only select, and much less
costly...)

> I think it would make sense to sync in both directions while we have an
> IMAP connection to a folder anyway. Especially with lots of folders, it
> *might* be a performance win (it wouldn't hurt in any case). More
> importantly, in case offlineimap is interrupted, we would have more
> folders already synced in a complete (ie 2-way sync) way, rather than
> having all of them synced only in one direction.
> Would people be interested in such a change?

Yes, that would make sense to me, and while my current IMAP server is
much less costly to SELECT on, it has much higher latency so reducing
the number of synchronous operations would be a performance win.

(What I would *really* love is if the difference between "folder
deleted on server" and "folder created on local" was noticed and the
create propagated though.  Plus a pony. ;)

Regards,
    Daniel
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons