Re: Fetching short text snippet for mails

--On December 1, 2014 22:39:13 -0800 Timo Sirainen <[email protected]> wrote:

> Nowadays many mail clients want to show about 100 chars of the beginning of
> mail, so there should be a nice and efficient way for clients to request
> this. I'm now wondering what would be a nice IMAP way of implementing this.
> Does anyone have some suggestions? There's what I've come up with so far:
> 
> a) FETCH n (SNIPPET)
>  - Would require writing a new RFC (or just use X-SNIPPET for internal use)
> 
> b) FETCH n (ANNOTATION (/vendor/vendor.dovecot.snippet))
>  - Would require implementing ANNOTATE, which is a lot of work. But it could
> also be implemented just minimally for this specific command.  -
> Standardizing vendor.dovecot.snippet would probably require new RFC
> 
> c) CONVERT n ("text/vnd.dovecot.snippet" ("length" "100")) BINARY[BODY]
>  - Would require implementing CONVERT, which is a lot of work. But it could
> also be implemented just minimally for this specific command.  -
> Standardizing vnd.dovecot.snippet would probably require new RFC
> 
> d) CONVERT n ("text/plain") BINARY[BODY]<0.100>
>  - CONVERT RFC says it's legal to convert entire multiparts, but doesn't say
> exactly what should be done with them. This is probably a valid use case
> though.  - Downside to this compared to others is that this always fetches
> the first 100 chars, while the others could also be smarter and skip over
> quoted text and such.
> 
> I think I'm leaning towards b)

I'm leaning towards a variant of a. Server advertises capability SNIPPET=BASE
indicating it implements the "BASE" snippet algorithm (the one we'll define in
the base spec). We can define vendor-specific and other algorithms as needed
via fcfs (vendor) or expert review (non-vendor) registry. If client doesn't
care about the algorithm, it can FETCH (SNIPPET) which will return the snippet
algorithm the server prefers (usually for performance/caching reasons). If
client cares about snippet algorithm, it can ask for its preferred algorithm if
available (e.g., FETCH (SNIPPET=vnd.dovecot.v1)) or decide to use its built-in
fallback if it doesn't like algorithms available. Snippet algorithms are
immutable for caching/etc. Using named algorithms allows us to standardize a
good enough base algorithm rather than being imprecise/non-interoperable or
aiming for rough consensus on a single algorithm when it may not be achievable.

If our "base" algorithm is good enough, it will probably win in the market. If
not, a better algorithm can be created. This balances deterministic behavior
(the snippet algorithm name precisely determines the behavior) with
adaptability. But it keeps the server implementation simple. If we decide the
base algorithm shouldn't cover HTML content; then we can introduce an
HTML-supporting algorithm later (after we complete the base spec) and might
have two popular algorithms (not necessarily a bad thing).

I don't like b -- the Annotate extension is primarily for mutable data and
requires support for search/sort/store/condstore/context/ACL bits/etc. It's
very helpful to server implementers to separate mutable from immutable data.
Snippet data needs to be immutable to maximize caching efficiency. Adding magic
"immutable" annotations is ugly as it requires special-case code in the
commands that support annotate.

I don't like c or d because CONVERT is too complex and it's not really designed
for optimal server behavior (where there are a small enough number of options
that the server can pre-compute/cache when appropriate).

		- Chris

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext