From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.42.218.138 with SMTP id hq10cs19103icb; Sat, 18 Dec 2010 11:16:37 -0800 (PST) Received: by 10.224.11.19 with SMTP id r19mr2215359qar.380.1292699797064; Sat, 18 Dec 2010 11:16:37 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id x6si3622611qcq.153.2010.12.18.11.16.36; Sat, 18 Dec 2010 11:16:37 -0800 (PST) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 94DF118583BE; Sat, 18 Dec 2010 14:16:36 -0500 (EST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by rubyforge.org (Postfix) with ESMTP id 9636418583BE for ; Sat, 18 Dec 2010 14:04:55 -0500 (EST) Received: from icsi.berkeley.edu (samurai.ICIR.org [192.150.187.48]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id oBIJ4RPX015429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Dec 2010 11:04:29 -0800 (PST) Date: Sat, 18 Dec 2010 11:04:27 -0800 From: Matthias Vallentin To: James Taylor Message-ID: <20101218190427.GU60419@icsi.berkeley.edu> References: <1271023429-sup-9851@zyrg.net> <1271249704-sup-1088@masanjin.net> <1271254358-sup-3024@pinkfloyd.chass.utoronto.ca> <1271260552-sup-9153@masanjin.net> <1271261164-sup-4109@pinkfloyd.chass.utoronto.ca> <20101215081955.GF568@icsi.berkeley.edu> <1292432651-sup-6834@jamestaylor.org> <20101218051216.GS60419@icsi.berkeley.edu> <1292649662-sup-8863@jamestaylor.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1292649662-sup-8863@jamestaylor.org> X-PGP-Fingerprint: 8A3B 1323 B469 CCBA 54D3 3BCC D5E7 8DF5 9C8D 4B41 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sup-talk , Ben Walton Subject: Re: [sup-talk] current state of synching upstream? X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.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