Re: [Extra] Discussing SNIPPET

[Michael Slusarz <[e-mail]>]

> On September 17, 2018 at 5:52 AM Bron Gondwana <[e-mail]> wrote:
> 
>     a) Naming.  The great difficulties, naming and cache invalidation! (and yep, we've got the second one too).  Should it be called SNIPPET, or something else like PREVIEW?  I'm asking largely because JMAP used "SearchSnippet" to refer to a fragment of matching text with terms hilighted.  And JMAP used "preview" for the short piece of text (up to 256 characters) that represents the email content.
> 
I don't have a personal attachment to SNIPPET (other than we already implemented with that terminology, but that's easily worked around by some internal aliasing).

PREVIEW makes sense if we are looking to a future where additional algorithms would be developed.  As Chris points out, if you have algorithms that return both text blobs and something like image data, preview makes more sense semantically than snippet.

I have no objection if we wanted to change the label.


>     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.
> 
I spent quite a bit of time formulating the logic behind this topic when drafting the spec. Reproduced here for convenience:

-----

A server SHOULD strive to generate the same string for a given message for each request. However, since snippets are understood to be a representation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message snippet is immutable for a given message. This relaxed requirement permits a server to offer snippets as an option without requiring potentially burdensome storage and/or processing requirements to guarantee immutability for a use case that does not require this strictness.

----

I would love to hear feedback what parts of this are weak or what parts need to be explained further.

I was thinking less about the situation of a server invalidating its cache rather than the scenario where a server loses its cache.  Demanding that server upgrades ensure that its algorithm stays exactly the same across versions, in order to rebuild exactly the preview data, is a burden I don't think is useful to enforce.  No user is going to be confused if their preview text suddenly differs across mail sessions.

Feedback so far doesn't seem to indicate this is too troubling of a design decision.  As mentioned above, I welcome feedback on how this can be explained better in the document.


>     c) Length: 
> 
>        The server SHOULD limit the length of the snippet text to 100
>        characters.  The server MUST NOT output snippet text longer than 200
>        characters.
> 
> 
>     I would prefer to bring this up to more like 200 for should and 256 for MUST NOT.  100 is a pretty short preview on big screens.  I'd also be willing to have a way for the client to hint for shorter previews to save network bandwidth, but have servers generally store 256 chars.  The syntax makes it quite easy to add a MAXLEN=80 or whatever to the fetch command.
> 
100 characters was selected via an informal survey of several different clients, both mobile and desktop, and how they currently display preview-like information in their UI.  It's probably a bit mobile-centric, since I had more of those applications available at the time.

More important, that analysis was probably too English-centric.  English is quite compact compared to many other languages, so it's probably a bad example to use when trying to determine ideal lengths (see, e.g., https://www.w3.org/International/articles/article-text-size).

200 characters seems just as arbitrary :)  But arguing over 100 extra characters stored per message is probably not a fight worth pursuing.  So I don't have a strong opinion on raising to 200 or max length as 256.  Although 256 isn't all that special since we are talking UTF-8 characters, not bytes, so landing on a power of 2 doesn't seem that necessary (just say 250 characters?).

MAXLEN seems like overkill though.  If a server is buffering output, we're not going to save that many network packets if a client requests partial text, since the use-case of preview is only to load data for the mailbox viewport.  And it adds more complexity on server side that doesn't seem to give us much benefit.

If we really wanted some sort of maxlen, for consistency sake it probably makes more sense to implement as <<partial>> syntax anyway.

michael