66 lines
2.7 KiB
Plaintext
66 lines
2.7 KiB
Plaintext
|
MBOX-Line: From dinh.viet.hoa at gmail.com Mon Mar 9 16:54:38 2015
|
||
|
|
To: imap-protocol@u.washington.edu
|
||
|
|
From: "Hoa V. Dinh" <dinh.viet.hoa@gmail.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: <CAP1qinY-d_fpmfwJ=04GUZhAnkZpPxzwMGfVdn8--4z=tJT5_w@mail.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>
|
||
|
|
Message-ID: <B79CBCA4E66D446690A5A91A7A88BA48@gmail.com>
|
||
|
|
|
||
|
|
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 (mailto: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/08be8be3/attachment.html>
|