50 lines
3.1 KiB
Plaintext
50 lines
3.1 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Mon Mar 9 17:25:42 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
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: <CAP1qinaEv5ZOC0rpXWdHhE=phLW5=6iWkiseb715-hZ6b85A4A@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>
|
|
<B79CBCA4E66D446690A5A91A7A88BA48@gmail.com>
|
|
<CAP1qinaEv5ZOC0rpXWdHhE=phLW5=6iWkiseb715-hZ6b85A4A@mail.gmail.com>
|
|
Message-ID: <1425947142.1718611.238135065.31CDBC0E@webmail.messagingengine.com>
|
|
|
|
|
|
|
|
On Tue, Mar 10, 2015, at 11:15 AM, Imants Cekusins wrote:
|
|
> > text protocol is neglectable in term of CPU usage ..., compare to let's say indexing of emails for search.
|
|
>
|
|
> well indexing is another topic. business email servers may or may not
|
|
> index email. of course, there is virus scanning, spam filtering - all
|
|
> this consumes resources.
|
|
>
|
|
> all I am saying: current protocols are wasteful from several points of
|
|
> view and can be simplified.
|
|
>
|
|
> if anything, simpler protocols would lead to
|
|
> - fewer production issues,
|
|
> - shorter development time (for email server developers),
|
|
> - more email server implementations, (choice is good)
|
|
> - better protocol compliance (simpler protocol makes it easier to comply with).
|
|
> - more robust mail delivery (less confusion over protocol)
|
|
|
|
So it looks like we're talking about SMTP more than IMAP here. One thing with the client<->server protocol is that you can do a lot of pre-calculation and caching on the server, particularly if you know what fields clients are likely to request. If you're re-creating the ENVELOPE on every read, then your server will be slow for sure.
|
|
|
|
But yes, simpler protocols are good for a lot of things. Text vs not text is not so much of a big issue there though, if you can just load a JSON library or even (cough, splutter) an XML library and get on with business, it doesn't matter what the wire protocol is so much. A protocol which is nicely regular and easy to parse/recreate is valuable, because then you can proxy it easily.
|
|
|
|
We use nginx as an IMAP proxy, but it all it does is the authentication step, and then provides a dumb stream proxy to the backends. I would love if it was easy to make it a bit more protocol aware, so we could easily inject a notice to the proxy that this backend was going away, and to switch the connection to this new replica. Of course, that sucks anyway because of selected mailbox state, and THAT would need to be moved to the replica - or uploaded to nginx and streamed back in. Messy either way. Having that state removed so that you don't need to serialise it to a new backend would make me very happy.
|
|
|
|
Bron ( or just stop having connections that persist for days )
|
|
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|