Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

Brandon Long <[email protected]> Mon, 9 Mar 2015 17:01:16 -0700
Newsgroups gmane.mail.imap.general
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 <[email protected]> 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
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol