Re: [Extra] Discussing SNIPPET
Bron Gondwana <brong@fastmailteam.com> Tue, 18 September 2018 07:54 UTC
Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44C130DDE for <extra@ietfa.amsl.com>; Tue, 18 Sep 2018 00:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=I9pHmVqL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzZ5WTcH
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ7nkTjrLmiz for <extra@ietfa.amsl.com>; Tue, 18 Sep 2018 00:54:00 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17D3127AC2 for <extra@ietf.org>; Tue, 18 Sep 2018 00:54:00 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9D75721E59; Tue, 18 Sep 2018 03:53:59 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 18 Sep 2018 03:53:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=I9pHmVqLgxEDyGeGTRD+eq CCeM2m/0x5ZQ294tDBbDyozFD5AE9kehIF+ECoIVw2MPuRscKxVLBBj6MajMwBVE u7Eqk01BqwRVkLkvc4keW/URFY+a1S9vPXQS8d0DgGmvdc/HT+yDO/7aPoyAwlPV KKqlqsGSUg5cc1sGE454QTyAp3GCKHaKtxFHHT/1ecGbAfqOMR8U22+23rkyiaTJ BoYDWRtt0E7FWzkufm1SOxkuG2GMBJ9WBYnOd/R7eajktVg4KXO/EDvOh7kOZs6B 5+eJ1iZfGkkx1XUUjIghCRSrj/Z1e5oWxIv7Gp18C5snVCVH9arL0boeEQs81ypQ ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9XKzTX A/7z/kXyxjAEoSTiVWvngU/3xqFAgX7isPHkY=; b=WzZ5WTcH4ZeBoMWG3gA4cd YI9d92YruX9NQQNoBl4KsDgPtNWIhMVlG7YQO9Mdze3DpyuoDRnmvfK6g3YbAG0S Nb6iP9tpZgP6pxdVSMfgZK5y0bGlQEgjMxtFGxa1lbOeRorwCVAzKCcqh0erUepU 2b3tLo/jDXm61FyfsYlqtdUAYc6CRqQQTOL0jx6X4IcnbU/zxf0iEH7QOHXqogsk UCeIBIdkZHCkRVG29pYV7K6Zec6ulyd7P1Mc0sPwcLoaJUOYk9SrzYpaO8v7dzmM v21GYl2a5JFn/whyofHUPShkFRxZLUQDKOf1n/dwrJAo+U+6GtMkHpytEn07TKUA ==
X-ME-Proxy: <xmx:Fq-gW5xlJjDTXSI_4Nq62Rup8Z8OLHqes1E-gIAfwtHzArh-OVZNnQ> <xmx:Fq-gWz15XWEXfPdLi9BlRuMqysmKnIkL9R5w7MwujN3oOMSOsugl-Q> <xmx:Fq-gW_56FfPGO8-cQ5DpC63tXRrVlLq69uJkwJ9TQQc3-9a10U_bQw> <xmx:Fq-gW-XHDiAhbHMV2Arsrn03vIhAkIWBIpKTHXSLN96byurMnhtepg> <xmx:Fq-gW2AolRnqhm_wP4Xc7cxUxm2rPVpJW-IYDqCRtJU28-nbygURIw> <xmx:F6-gW8hu283gnkvmd3a3lSAj3GYkA3gc10_K8cOu8eYDYnPwXtMweA>
X-ME-Sender: <xms:Fq-gW74bqP4gLcBjxi9NvP0hbGvPRhMBextTDqg3RyMqxQ3bX752SQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 944C1E2319; Tue, 18 Sep 2018 03:53:58 -0400 (EDT)
Message-Id: <1537257238.2278116.1511804688.496B30F1@webmail.messagingengine.com>
From: Bron Gondwana <brong@fastmailteam.com>
To: Josef Jeff Sipek <jeff.sipek@dovecot.fi>, Chris Newman <chris.newman@oracle.com>
Cc: extra@ietf.org, Michael Slusarz <michael.slusarz@open-xchange.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_153725723822781160"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-15b169d8
References: <0a9f6019-776c-49ff-a800-af494374ce59@sloti22d1t06> <3E644603-F6E1-438E-841C-B4DE45DD8136@oracle.com> <20180918074720.GB1384@meili>
Date: Tue, 18 Sep 2018 17:53:58 +1000
In-Reply-To: <20180918074720.GB1384@meili>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/GZ651O_YuUuYAd_1-CuBDVqyYtc>
Subject: Re: [Extra] Discussing SNIPPET
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 07:54:03 -0000
On Tue, Sep 18, 2018, at 17:47, Josef 'Jeff' Sipek wrote: > On Mon, Sep 17, 2018 at 17:31:23 -0700, Chris Newman wrote: >> On 17 Sep 2018, at 4:52, Bron Gondwana wrote: > ... >>> b) Cache Invalidation. Ho hum. Is this an immutable property? If so,>>> what happens if the server implementation changes? I'm quite >>> happy to>>> call it "softly immutable" myself - it might not be exactly the same>>> bytes, but you can use the old version without major problems. >> >> The 'softly immutable' option works for me. However, I'll propose an>> alternative so we can contrast two reasonable options. We could add >> a way to>> fetch a FUZZY algorithm identifier for a given folder. >> Something like:>> >> C: A043 STATUS blurdybloop (FUZZYALG) >> S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0")) >> >> A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is >> immutable unless>> the FUZZYALG string changes. This has some non-trivial server >> implications,>> but if clients really need predictable PREVIEW caching behavior, >> this is a>> protocol model I'd be willing to implement to provide that. > > For what it's worth, in Dovecot we cache the generated > snippet/preview along> with a version number and take the 'softly immutable' approach. For > example, an email with body of "foobar" would turn into > "1foobar" in the> cache file. When a client FETCHes it, we strip the version. We > haven't had> the need to up the version yet, but at least in theory it should > provide us> with a way to tweak the snippet algo and know which cached values > are stale. We do something similar at FastMail - we have a keyword (currently $X-ME-Annot- 2) which is a version number for the logic which generated the preview and a couple of other keywords like $HasAttachment by parsing the message content. > I'm not fully caught up on the discussions here so maybe I'm missing > something, but I was under the impression that the algo can be > selected per> **email** so wouldn't it really have to be a FETCH * FUZZYALG?. I > don't quite> understand what the above STATUS accomplishes; I guess it is > something like> a uidvalidity for snippets in a folder but I'm not convinced > that it is> worth it. If you want to have the latest snippet, just FETCH it. I agree with that! It's small enough that re-fetching isn't a big deal if you are worried that it might be old - and the cost in roundtrips to check the version first plus the added complexity isn't worth it. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com
- [Extra] Discussing SNIPPET Bron Gondwana
- Re: [Extra] Discussing SNIPPET Chris Newman
- Re: [Extra] Discussing SNIPPET Josef 'Jeff' Sipek
- Re: [Extra] Discussing SNIPPET Bron Gondwana
- Re: [Extra] Discussing SNIPPET Michael Slusarz