Re: Fetching short text snippet for mails

On 6 Dec 2014 00:25, "Michael M Slusarz" <[email protected]> wrote:
>
> 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.
>

+1 - Also I really don't think every octet of the preview needs specifying
rigidly.

> michael
>
> ___________________________________
> Michael Slusarz [[email protected]]
>
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

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