IETF Logo Mail Archive

Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

Bron Gondwana <brong@fastmail.fm> Mon, 20 February 2012 11:42 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 BD81121F8701 for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 03:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level:
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 FUmlN+OwvK9m for <imap5@ietfa.amsl.com>; Mon, 20 Feb 2012 03:42:03 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2D21F8636 for <imap5@ietf.org>; Mon, 20 Feb 2012 03:42:03 -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 D453B20BCF for <imap5@ietf.org>; Mon, 20 Feb 2012 06:41:57 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute5.internal (MEProxy); Mon, 20 Feb 2012 06:41:57 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=mesmtp; bh= fGzUwIc0twHIuOQiHzbOmx5+pBM=; b=g6fnOO0TCOi0PH3xCf6PHl4NL2JIfeOy dMdr0C//lCwyaEEnYHmCa2hkq4zJH8vinpWx6PcyNSOe1JIuJu/1J+EOOz+2vFvU LGsSlKqYkZqP2Y1btZMUoy/P4wuI9jpE3MgTqMamEEEt7eIVWD5OZRW5kZEo2lEJ TPxsA/W1EBk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:references:subject :in-reply-to:date; s=smtpout; bh=fGzUwIc0twHIuOQiHzbOmx5+pBM=; b= OEOmKf1ueS5fomOXhNhc0lgLgEzLLEyAr2G3HV76yXqhNVAcpael/6VkJZYBJq+u Wl3cNwNlPxWZoZESjTgUlA5inoZ5qPThK9ZCU6DgWouZ17oumM1MSVkGJ30z7/Pi rLlpUGIn1sWMItgwWWNCe90ruqFu75bWUbqf9t/lMr8=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id ABC75A000A0; Mon, 20 Feb 2012 06:41:57 -0500 (EST)
Message-Id: <1329738117.22774.140661038826265@webmail.messagingengine.com>
X-Sasl-Enc: RZlP8H3Ri8kJcGTr9aBG4G+b9iSxSuga1fbKepDw6KrN 1329738117
From: Bron Gondwana <brong@fastmail.fm>
To: Adrien de Croy <adrien@qbik.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Mailer: MessagingEngine.com Webmail Interface
References: <alpine.LSU.2.00.1202161626400.30682@hermes-2.csi.cam.ac.uk> <4F3D6E57.8010301@qbik.com> <alpine.LSU.2.00.1202171127330.30682@hermes-2.csi.cam.ac.uk> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <alpine.LSU.2.00.1202191832430.12769@hermes-2.csi.cam.ac.uk> <20120219192604.GA11323@launde.brong.net> <4F415C07.3040100@qbik.com> <20120219220835.GB12549@launde.brong.net> <4F417EF5.6030809@qbik.com> <20120219233901.GA13600@launde.brong.net> <4F41952B.8020809@qbik.com>
In-Reply-To: <4F41952B.8020809@qbik.com>
Date: Mon, 20 Feb 2012 12:41:57 +0100
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [imap5] Feature set? - was Re: 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: Mon, 20 Feb 2012 11:42:08 -0000

On Mon, Feb 20, 2012, at 01:34 PM, Adrien de Croy wrote:
> i'm just talking about good old file system file copy, without parsing.

Just our of interest, are you doing this with BURL now?

If not, then a requirement to translate during copying is not an additional
imposition on top of the IO and CPU hit you're currently getting from
two different copies being sent through your system(s).

If so, how do you handle the case where the client wants to store a
BCC field in their "Sent Items" folder as a record of who it was
really sent to?

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm

v2.23.0 | Report a Bug | By Email