Re: draft-melnikov-imap-search-res

Timo Sirainen <tss@iki.fi> Tue, 19 October 2004 17:41 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfOpJ008053; Tue, 19 Oct 2004 10:41:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JHfOBq008052; Tue, 19 Oct 2004 10:41:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfMqb008022 for <ietf-imapext@imc.org>; Tue, 19 Oct 2004 10:41:23 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id B280D1C386DA; Tue, 19 Oct 2004 20:41:14 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 211D81C3531B; Tue, 19 Oct 2004 20:41:10 +0300 (EEST)
In-Reply-To: <417542E6.50902@isode.com>
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <A988B56A-21EB-11D9-8450-000393CC2E90@iki.fi> <417542E6.50902@isode.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-8--358615198"
Message-Id: <0F855184-21F6-11D9-8450-000393CC2E90@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: IMAP Extensions WG <ietf-imapext@imc.org>
From: Timo Sirainen <tss@iki.fi>
Subject: Re: draft-melnikov-imap-search-res
Date: Tue, 19 Oct 2004 20:41:09 +0300
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi
X-Spam-Level:
X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.0.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On 19.10.2004, at 19:37, Alexey Melnikov wrote:

>> If client sends SEARCH + FETCH << pipelined, nothing prevents server 
>> from giving all the FETCH replies before the SEARCH reply, right?
>
> The server shouldn't reorder the commands if there are any data 
> dependencies. "<<" is a very explicit indication that there are.

Reordering here wouldn't affect results, only the order in which the 
results are sent to client.

> Is there any particular reason why you think that a server should 
> return FETCH responses before the SEARCH response?

Mostly just performance benefits. Server could process the two commands 
simultaneously in one loop.

But you also mentioned (NORESULT) which would make this possible in any 
case.