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
