Re: [Extra] SNIPPET (now PREVIEW) draft update

["Bron Gondwana" <[e-mail]>]

That's my attitude to previews too, they don't "change" but they might not be byte identical if fetched again later due to changing server algorithms. The old value is never "wrong" though, short of buggy servers. 
 
Bron.
 
On Sat, 10 Nov 2018, at 13:14, Timo Sirainen wrote: 
> I think from IMAP protocol purity point of view it would be nice if we didn't have fields that could suddenly change without any indication. But from a practical point of view: Who cares, really? The previews are mainly intended for clients that don't have a local cache. Even if we implemented modseq changes for previews, would any client (that has more than a couple of users) ever really use them? I find it doubtful. More likely these additional requirements would make it more difficult for servers to implement this feature, so the clients wouldn't have it at all. 
>  
>> On 9 Nov 2018, at 21.14, Brandon Long <blong=[e-mail]> wrote: 
>>  
>> Do we think this is likely to be used for full-sync clients? Theoretically, those could just generate their own snippets locally from the rest of the data. 
>>  
>> For online clients, the preview would just be part of what they download to display the message list. 
>>  
>> Without QRESYNC, we still have some ugly polling, though obviously PREVEIWS are larger than UIDs. 
>>  
>> OTOH, I feel we already have part of this type of problem today, where improvements to our parsers or encoding detection might change our response to any 
>> given message based request, but obviously we won't rev the UIDVALIDITY folders on every bi-weekly release when its only ever going to affect a small number of messages. 
>>  
>> Brandon 
>>  
>> On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt <stujenerin=[e-mail]..org <mailto:[e-mail]>> wrote: 
>>> I know I brought this up years ago, but I'm not sure I ever saw solid  
>>>  resolution. If, as proposed, the Preview is mutable, then are we not  
>>>  addressing how to efficiently identify and sync changes that might have  
>>>  been made to it? If I were a client dev, I'd want to have the most  
>>>  recent Preview for a message because a new version likely means: 
>>>  a) server fixed a defective preview 
>>>  b) server improved preview's value-to-user 
>>>   
>>>  Mutable data without an efficient way to sync leads to ugly polling. 
>>>   
>>>  - Stu 
>>>   
>>>  On 11/8/2018 7:03 AM, Bron Gondwana wrote: 
>>>  > Hi Michael, 
>>>  > 
>>>  > Thanks again for submitting this, and apologies that I haven't done a 
>>>  > thorough review yet - it's on my todo list and I expect to do so soon. 
>>>  > 
>>>  > The ONLY remaining question was length. 200 is good, but JMAP says 255 
>>>  > and consistency will make it better. Unless you have a strong reason to 
>>>  > lock it down to 200, would you consider changing it to "no more than 255 
>>>  > octets" with an understanding that there's no requirement that servers 
>>>  > have to store that much, just that clients must be willing to accept 
>>>  > that much. That will keep everything consistent. 
>>>  > 
>>>  > Other than this, we believe we're ready to take this document to working 
>>>  > group last call, which I intend to do once I've heard back from you - 
>>>  > it's easy to fix this up during last call. 
>>>  > 
>>>  > Thanks for your work and for getting us the update in time for this meeting. 
>>>  > 
>>>  > Cheers, 
>>>  > 
>>>  > Bron. 
>>>  > 
>>>  > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote: 
>>>  >> I've submitted an update to the (formerly snippet, now) preview draft 
>>>  >> incorporating feedback received from this list and other implementers. 
>>>  >> 
>>>  >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET". 
>>>  >> Also, increased recommended preview size to 200 characters 
>>>  >> (previously: 100). 
>>>  >> 
>>>  >> Will not be able to remotely join IETF 103 meeting as I am traveling, 
>>>  >> but wanted to make sure this draft was updated before then. 
>>>  >> 
>>>  >> michael 
>>>  >> 
>>>  >> _______________________________________________ 
>>>  >> Extra mailing list 
>>>  >> [e-mail] 
>>>  >> https://www.ietf.org/mailman/listinfo/extra 
>>>  >> 
>>>  > 
>>>  > -- 
>>>  > Bron Gondwana, CEO, FastMail Pty Ltd 
>>>  > [e-mail] 
>>>  > 
>>>  > 
>>>  > 
>>>  > 
>>>  > _______________________________________________ 
>>>  > Extra mailing list 
>>>  > [e-mail] 
>>>  > https://www.ietf.org/mailman/listinfo/extra 
>>>  > 
>>>   
>>>  _______________________________________________ 
>>>  Extra mailing list 
>>>  [e-mail] 
>>>  https://www.ietf.org/mailman/listinfo/extra 
>> _______________________________________________ 
>> Extra mailing list 
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/extra 
>  
> _______________________________________________ 
> Extra mailing list 
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/extra 
>  
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [e-mail]