IETF Logo Mail Archive

Re: [imap5] Designing a new replacement protocol for IMAP

Bron Gondwana <brong@fastmail.fm> Thu, 16 February 2012 19:18 UTC

Return-Path: <brong@fastmail.fm>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0094121E805B for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 11:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.56
X-Spam-Level:
X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQZdX9V6L+iQ for <imap5@ietfa.amsl.com>; Thu, 16 Feb 2012 11:18:30 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E83AF21E8053 for <imap5@ietf.org>; Thu, 16 Feb 2012 11:18:29 -0800 (PST)
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3E18520EDB for <imap5@ietf.org>; Thu, 16 Feb 2012 14:18:29 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 16 Feb 2012 14:18:29 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=nxSsKcrJDgt0ax9zdoiThdHg vZU=; b=kybsKT9T6JgorM2wuj0s0yx2MNuiIeSHL5QGJIkDKWY748iXZ25IsVhH YPC9I7gcfHN/8hE1odE3j5LveGjsSMxxmvK6VbXD8hdqB6vkcX1aJWwpnvp3iaKN R2eKEGwJsGStGn2q7gHoz/eBrPDk54iIrJfPThN2No9SLSTD7uI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=nxSsKcrJDgt0ax9zdoiThdHgvZU=; b=m1cJyroLqkXFtxWwFweflgan+b/V FdE9xB5074bPAjhCNEy0eCc/vXKkKXUXxOg+Nv+FXVmgq3TiopfH2d44wDeGgn9v 9hUPk8pOQAF2xRhFX5tki1vmrs+WwQjWNMwterzRGVw2of+PSk1n8HMs0JFzNgs+ wibT9GPpPRKnrUs=
X-Sasl-enc: ptbGrzFqarGTUvMcocm4csfPLEg73MrdIHaLUl0fRTW3 1329419908
Received: from localhost (99.249.9.46.customer.cdi.no [46.9.249.99]) by mail.messagingengine.com (Postfix) with ESMTPSA id CB14248248A; Thu, 16 Feb 2012 14:18:28 -0500 (EST)
Received: by localhost (Postfix, from userid 1000) id 4C8A4118A4A; Thu, 16 Feb 2012 20:18:27 +0100 (CET)
Date: Thu, 16 Feb 2012 20:18:27 +0100
From: Bron Gondwana <brong@fastmail.fm>
To: Tony Finch <dot@dotat.at>
Message-ID: <20120216191827.GA22862@launde.brong.net>
References: <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <alpine.LSU.2.00.1202161126410.31357@hermes-2.csi.cam.ac.uk> <1329396103.8954.140661037328961@webmail.messagingengine.com> <alpine.LSU.2.00.1202161305220.30682@hermes-2.csi.cam.ac.uk> <20120216145745.GB21339@launde.brong.net> <alpine.LSU.2.00.1202161520460.31357@hermes-2.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.1202161520460.31357@hermes-2.csi.cam.ac.uk>
Organization: brong.net
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
Subject: Re: [imap5] Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 19:18:35 -0000

On Thu, Feb 16, 2012 at 03:21:55PM +0000, Tony Finch wrote:
> Bron Gondwana <brong@fastmail.fm> wrote:
> > On Thu, Feb 16, 2012 at 01:06:11PM +0000, Tony Finch wrote:
> > > Bron Gondwana <brong@fastmail.fm> wrote:
> > > >
> > > > Not really.  Existing servers would be a lot more efficient with a query
> > > > which limited to a single "folder", for sure - because they could optimise
> > > > it.  But it's no different than an SQL query across a partitioned table.
> > > > It means your in-memory-state needs to be big enough to accommodate all
> > > > the mailboxes that might be in the regular searches, of course.
> > >
> > > Have you seen UW-IMAP's in-memory state? :-)
> >
> > Nup - I've seen Cyrus' though.  It could be trimmed considerably if we
> > had to...
> 
> The problem is UW-IMAP is structured so it can only handle one mailbox at
> a time.

Cyrus too.  Which is a reason for not forcing the model of "one big
pool".  I'm not committed to one big pool - if there's a syntax for
joining smaller pools together to sort/search across them.  This is
one of the "more work for the server, less for the client" options,
where we assume people writing servers are slightly more clueful.

Besides, they'll have a test to run :)

Bron.

v2.23.0 | Report a Bug | By Email