Re: Fetching short text snippet for mails

Inline...

On 12/11/14 11:53 AM, Paul Smith wrote:
>
> On 11/12/2014 15:47, Stuart Brandt wrote:
>> Hi Paul -
>>
>> My responses are inline
>>
>> On 12/11/14 8:48 AM, Paul Smith wrote:
>>>
>>> On 11/12/2014 13:41, Stuart Brandt wrote:
>>>> Is snippet intended to be immutable? A server figuring out how to best
>>>> parse an HTML body part and offer up of the most meaningful snippet
>>>> for a user almost assuredly will result in versioning of the
>>>> extraction algorithm, thereby leading to the potential for a mutable
>>>> snippet element.
>>>
>>> Does it matter?
>>
>> Yes. Mutable implies the need for synchronizing snippet changes
>> between client and server, which in turn might have implications for
>> QRESYNC/CONDSTORE or other synchronization approaches.
>
> But does it matter?
>
> What I mean is, if one day, the SNIPPET gets returned as:
>
> "Hi Paul - My responses are inline On 12/11/14 8:48 AM, Paul Smith wrote: "
>
> and the next day it would have been returned as:
>
> "Hi Paul - My responses are inline Yes. Mutable implies the need for
> synchronizing snippet changes"
>
> does that really matter? Will it cause real problems if the client has
> cached the old snippet and doesn't refresh it?

The real problem is an impact to the user experience.

Setting text/plain aside because in multipart/alternative cases the 
text/html part is what's most useful for snippet generation...we see all 
sorts of interesting malformed HTML variants that are expected to be 
handled gracefully. Generation of snippet from such cases can yield some 
pretty useless snippets. When such a case is found and a workaround is 
released, it would be in the user's best interest if the prior ugly 
snippet were "fixed".

When this sort of issue comes up today with client-side snippet 
generation (or HTML rendering for that matter), a new app/client is 
released and in some cases it's auto-updated on the user's device. In 
the end, the user experience is made whole.


>
>>
>> I don't dispute the value of fixed sized snippet for caching. What I'm
>> questioning is whether all clients and all servers should use a single
>> fixed size indicated by this spec. Whether it be 'relaxed' vs.
>> 'compact' list spacing in desktop Web clients, or pinch/stretch
>> gestures performed on a tablet's message list, user viewable snippet
>> sizes are something that's been changing over the last few years.
>> Given these changes, something along the line of...
>> - server advertising its max snippet size
>> - client indicating how much of the snippet it wants
>> ...seems to be a bit more flexible than a fixed size.
> OK, as long as the server can specify its maximum size, and the client
> can't expect to get more than that. In that case, the server can just
> cache the maximum size and return a subset of that if the client wants
> less. If the client can request any size snippet, then the server could
> have to work it out each time.
>
>
> -
>
>
> Paul Smith Computer Services
> Tel: 01484 855800
> Vat No: GB 685 6987 53
>
> Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

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