Re: Fetching short text snippet for mails

Quoting Jan Kundrát <[email protected]>:

> On Tuesday, 2 December 2014 17:37:31 CEST, Cyrus Daboo wrote:
>> Efficient as in eliminating the current extra round trip of doing a  
>> FETCH BODY.PEEK[<section>]<<partial>>?
>
> I don't think a roundtrip would be neccessary.
>
> Sure, the client doesn't know whether it's a single-part text/plain,  
> or if it's a multipart/mixed with plaintext and HTML, or whether  
> it's something yet different. However, there's principally no  
> problem in issuing a blind BODY.PEEK[1] which will "get the right  
> thing" most of the time. One can play it extra-safe and ask for a  
> BODY.PEEK[1.1] as well, these are also pretty popular and the worst  
> case is wasting a tiny amount of bandwidth. It's OK to request a  
> non-existing part in FETCH anyway.

We've found this kind of blind-fetching technique isn't very useful,  
at least coming from the perspective of a client that has to handle  
1000's of concurrent users.

If building a mailbox listing, there's a good chance that  
envelop(-ish) data is cached on the server.  Once you start adding  
body fetches to this mailbox listing it becomes more expensive I/O  
wise to generate these responses.

And this doesn't work very well for multipart/alternative e-mails,  
especially since more and more of those messages have a [1] text/plain  
content of either "Go to URL http://example.com/ to view the contents  
of this message" or an automated down-converted representation of the  
HTML part that is difficult to read.

For a 50,000 foot preview of the message content, I have no issue  
relying on a server to figure out how to parse the  
multipart/alternative message and strip out the HTML tags in order to  
provide something useful.

michael

___________________________________
Michael Slusarz [[email protected]]

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