Re: [sup-talk] current state of synching upstream?

From: Matthias Vallentin <vallentin@ICSI.Berkeley.EDU>
To: James Taylor <james@jamestaylor.org>
Cc: sup-talk <sup-talk@rubyforge.org>,
	Ben Walton <bwalton@artsci.utoronto.ca>
Subject: Re: [sup-talk] current state of synching upstream?
Date: Sat, 18 Dec 2010 11:04:27 -0800	[thread overview]
Message-ID: <20101218190427.GU60419@icsi.berkeley.edu> (raw)
In-Reply-To: <1292649662-sup-8863@jamestaylor.org>

On Sat, Dec 18, 2010 at 05:25:05AM +0000, James Taylor wrote:
> Neither. The imap clients are read write, the only time this becomes a
> problem is when the imap client moves a message from new to cur. 

Is that the only operation the imap clients do? What happens if they
delete messages (or moved them to another source) and sup has that
message already in the index.

> Sup will not be able to find the message until the next time it polls
> (but this is mostly seamless, if I use the imap client I just poll and
> refresh in sup). This does imply that sup must be polling cur as well
> as new.

If sup polls both cur and new then there is no more benefit in keeping
new small to avoid long poll times for large maildirs. 

This brings me to my main sup question. What is the best strategy to
avoid overly large maildirs? Say I have around 10 maildirs, each of
which represent a separate source. The classic scheme that comes to mind
(and that I use with Mutt and Mairix) would be some horizontal
partitioning scheme according to time, i.e., creating a new tree of
maildirs at a certain time interval (e.g., quarterly could imply a
naming scheme for the top-level directories like mail-2010-1 to
mail-2010-4). Then, only the most recent partition needs to be polled.

The downside appears to be that each rotation adds, in the above
example, 10 new source entries to sources.yaml and requires switching
of polling in the non-current sources.

Does that sound tractable and aligned with sup's mail philosophy? 

   Matthias
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk