From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.42.218.138 with SMTP id hq10cs1929icb; Fri, 17 Dec 2010 21:13:08 -0800 (PST) Received: by 10.229.229.18 with SMTP id jg18mr358057qcb.276.1292649187130; Fri, 17 Dec 2010 21:13:07 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id g5si2162274qcq.34.2010.12.17.21.13.06; Fri, 17 Dec 2010 21:13:07 -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 91A0C1858367; Sat, 18 Dec 2010 00:13:06 -0500 (EST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by rubyforge.org (Postfix) with ESMTP id 27E8C18582EE for ; Sat, 18 Dec 2010 00:12:45 -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 oBI5CGkw011695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Dec 2010 21:12:18 -0800 (PST) Date: Fri, 17 Dec 2010 21:12:16 -0800 From: Matthias Vallentin To: James Taylor Message-ID: <20101218051216.GS60419@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1292432651-sup-6834@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 Wed, Dec 15, 2010 at 05:06:54PM +0000, James Taylor wrote: > For what it is worth, I've been using maildir-sync for almost six months > every day, no problems. I exercise it pretty hard since I usually have > at least four imap clients (mobile devices and such) accessing the > maildir simultaneously via dovecot imap. This looks like the scenario I envision. Two questions: - Do you use the IMAP clients as read-only clients or do you invoke sup-sync after the devices modify the maildir (or before polling in sup)? - Do you use sup-sync-back when changing message state via sup? From what I understand, this would be desirable to copy messages from new to cur in order to avoid a linear increase in poll times with growing number of mails in new. Matthias _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk