Re: IMAP SNIPPET extension (initial draft)

This message never seemed to make it to my mailbox, so doing a  
copy/paste job to respond...  This is a response to Stu's message from  
several days ago:

----------

On 5/4/15 1:56 AM, Michael M Slusarz wrote:

     7.  TODO

         1.  More explicit algorithm for text/plain processing?

         2.  Interaction with CONDSTORE (MODSEQs)?


Is this where details on the question of the snippet being  
mutable/immutable will be or does the mention of CONDSTORE here imply  
that it's assumed to be mutable?

Assuming the latter, it would be good to cover the cases that demand a  
mutable snippet + offer recommendations for clients that don't use  
CONDSTORE/MODSEQ regarding snippet fetch frequency. I'd sure hate to  
see all the "FETCH 1:* (UID FLAGS)" polling turn into "FETCH 1:* (UID  
FLAGS SNIPPET)"

----------

This was sort of my way to punt this issue for future discussion about  
mutable/immutable.

My personal view (and what i almost wrote) is that a client SHOULD NOT  
care whether a SNIPPET is mutable or not.  Since the whole point of  
SNIPPET is to provide some sort of *quick* means of generating a  
preview, it should not matter as to the exact content of the snippet.   
Once a client has a snippet it should use that text going forward as  
long as it retains that data locally.  Trying to sync snippet data  
destroys the main benefit of using SNIPPET in the first place: a cheap  
way of generating a preview.

Additionally, given the nature of the FUZZY algorithm, inherently  
there is no way of enforcing that a server use the same algorithm to  
generate identical output text, at least for any given algorithm  
selection.

I would argue that a server SHOULD try to honor a given algorithm  
request, but I don't think it should be a requirement to rebuild the  
SNIPPET.  I would imagine many caching/indexing servers would  
automatically generate snippet data at the time it first parses the  
message (i.e. on initial delivery), so that by the time a user  
requests a FETCH on the message the data is already generated.

My focus on the SNIPPET draft was to ensure that it is as fast as  
possible.  If a client is looking for specific or reproducible  
behavior when generating a preview, it can obtain that the way it  
always has been able to: by doing the preview generation locally.   
Alternative: we have to implement at least one determinative algorithm  
that ensures that the snippet data is identical across any two  
different server implementations.

In short, I personally think that SNIPPET has no interaction with  
CONDSTORE/MODSEQs.  But would be glad to open the conversation and  
hear from all those who disagree.

michael

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