How IMAP works under the hood
blog.lohr.dev
How IMAP works under the hood
1–10 of 78 posts
Re: How IMAP works under the hood
#2Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption.
HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
Re: How IMAP works under the hood
#3Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
The protocol has ossified and been entrenched. In general more efficient usage of IMAP relies on extensions to the protocol.
A modern replacement (JMAP) hasn't been adopted by major providers.
If you really cared about data transfer size you'd use something like Protobuf.
Re: How IMAP works under the hood
#4Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
Networked bytes generally don't matter, networked packets do. Would your proposed change move the needle on that?
Re: How IMAP works under the hood
#5Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
It could have, but for stuff you only do once per session that seems excessive. Better to have names that need no explanation, especially for stuff that I think is completely optional.
Re: How IMAP works under the hood
#6Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
Despite people always complaining about their perceived inefficiencies, standard protocols like IMAP or XMPP always seem to work on a crappy connection, when most of the modern web doesn't.
Re: How IMAP works under the hood
#7Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
Probably wrong context, but the more code I wrote, more I like the these `Has`+Noun style naming than just Noun. Reading `HasChildren` will give you a clearer expectation of what the function would do and return, while `Parent` gives far weaker indication.
Maybe they thought the same when they were designing the protocol.
Also, in the context of email, given the size of each mail (including headers and body), these bytes "waste" maybe insignificant.
Re: How IMAP works under the hood
#8I started writing a guide to IMAP back when I was working on an email client: https://github.com/rmccue/griffin/tree/master/docs/imap
Pulling large amounts of data for things like threading can be difficult on certain servers; my preferred approach ended up being to pull every ID and thread ID to maintain an in-memory tree. (This was, iirc, partially because Gmail’s implementation was slightly crippled with relation to threading.)
(I never finished the guide because I stopped on the project, alas - if IMAP were easier to work with, I might have finished it! And sadly, no JMAP support on Gmail, and the gateway was broken.)
Re: How IMAP works under the hood
#9Interesting no attempt has been made to make it at least be less heavy on networked bytes. Especially since it is old and was meant to be used on a connection with no compression or encryption. HasChildren could have been Parent, HasNoChildren could have been Leaf or Child. And so many more things.
The protocol has ossified and been entrenched. In general more efficient usage of IMAP relies on extensions to the protocol. A modern replacement (JMAP) hasn't been adopted by major providers. If you really cared about data transfer size you'd use something like Protobuf.
IMAP COMPRESS?
Re: How IMAP works under the hood
#10I've been working on some email stuff and I think probably four things are vexing about IMAP:
- The grammar is hard. I built a parser using lpeg and I'm incredibly glad I did--doing it ad hoc won't lead to good results.
- It's an asynchronous protocol. You can send lots of requests to a server and you have to tag them so you can match them up with responses later. You don't generally want to do that in a client; i.e. you don't want to do these transactional things over an async connection and track state across all of it. You want to like, block on deleting things, renaming things, sending things, etc.
- IMAP is multi-user--it's built around the idea of multiple clients accessing the same mailbox at the same time and streaming updates. Another thing you really don't want to deal with when building an email client.
- There's functionality that you basically shouldn't use; the big one is search. Even the specs more or less say "good luck using this".
You can group all this under the a heading of "we thought people would use this over telnet", but attachments and non-plain-text email I think made that non-viable.
I think this all means probably every non-web email client treats IMAP like POP and keeps its own store. I haven't done a survey or anything, but I'd be surprised if that weren't true.