87 lines
3.2 KiB
Plaintext
87 lines
3.2 KiB
Plaintext
MBOX-Line: From blong at google.com Mon Mar 9 17:01:16 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <B79CBCA4E66D446690A5A91A7A88BA48@gmail.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com> <54FBF289.3010202@psaux.com>
|
|
<7164.1425831184@parc.com>
|
|
<1425907661.1215497.237833469.1EDA571D@webmail.messagingengine.com>
|
|
<6506.1425915329@parc.com>
|
|
<B03452330F6149E180E449A493F28C2B@gmail.com>
|
|
<CAP1qinZdV1LW6XiWfqfk2A+TC6HsYsAWtT-KSffTNdOFqG_Tjw@mail.gmail.com>
|
|
<7782A916-12BB-488C-BD57-697FDB5D47E2@orthanc.ca>
|
|
<CAP1qinY-d_fpmfwJ=04GUZhAnkZpPxzwMGfVdn8--4z=tJT5_w@mail.gmail.com>
|
|
<B79CBCA4E66D446690A5A91A7A88BA48@gmail.com>
|
|
Message-ID: <CABa8R6t=B-buGCWwME5N6T6xEvr_aPpQVVK70GBNm2WgAa8oBw@mail.gmail.com>
|
|
|
|
We witnessed quite a big portion of cpu involved in un-dot-stuffing smtp
|
|
(and correcting line endings) and saved quite a bit of that with supporting
|
|
BDAT.
|
|
|
|
OTOH, I don't think IMAP parsing has been a large CPU issue for us,
|
|
partially because with LITERAL we already skip through the larger data
|
|
pieces.
|
|
|
|
Brandon
|
|
|
|
On Mon, Mar 9, 2015 at 4:54 PM, Hoa V. Dinh <dinh.viet.hoa@gmail.com> wrote:
|
|
|
|
> Unfortunately, mail servers have to deal with the existing world of emails,
|
|
> where there are charset encoding, MIME encoding, spinning disks and memory.
|
|
>
|
|
> Lots of those operation have to happen until every users of emails move to
|
|
> anything else than email.
|
|
> That said, spinning disks and memory might be still around.
|
|
>
|
|
> Also, I actually think that the text protocol is neglectable in term of
|
|
> CPU usage (and that?s also a subjective assessment), compare to let?s say
|
|
> indexing of emails for search.
|
|
>
|
|
> --
|
|
> Hoa V. Dinh
|
|
>
|
|
> On Monday, March 9, 2015 at 4:44 PM, Imants Cekusins wrote:
|
|
>
|
|
> Is your measurement data and methodology for this available online
|
|
> anywhere?
|
|
>
|
|
>
|
|
> this is a subjective assessment. Email servers are way too busy for
|
|
> what they deliver. I believe it is for these reasons:
|
|
>
|
|
> Parsing takes time. So does transfer decoding and charset conversion,
|
|
> unwrapping text, dot stuffing.
|
|
>
|
|
> It can be reduced to:
|
|
> no case conversion for commands; no parsing for commands even: a
|
|
> simple switch case statement suffice;
|
|
>
|
|
> no parsing for CRLF, empty line or DOT CRLF; actually, no content
|
|
> parsing at all is necessary for transmission;
|
|
>
|
|
> no transfer encoding / decoding (it is transferred as binary);
|
|
>
|
|
> no charset decoding: a single encoding is applied to the entire (text
|
|
> part of) the message.
|
|
>
|
|
>
|
|
> Simply from pragmatic point of view: if these tasks need not to be
|
|
> done, server is less busy and can process higher throughput.
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
>
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150309/02939ddd/attachment.html>
|