It's not independently difficult per se, it's just mismatched to the way that other protocols often work in a way that, in practise, few clients implement well. Most clients and libraries implement it as if it were request-response and as a result either produce wrong answers or are notably less efficient as you note.
> Every protocol works this way, nothing new.
No? POP3 and HTTP as easy examples are simple blocking request-response. Some do either pipelining or multiplexing with the command-tagging, but don't have unsolicited messages. I can think of only a few other comparable protocols with this paradigm but "every" is just not true.
> of course, otherwise how do you think notifications can work?
Yes? This is indeed _why_ it works this way. I don't know what you're correcting me about. It does this to implement notifications and liveness. We're agreeing.
> Never had any problem with Thunderbird
Thunderbird is one of the better implementers, yes. There are messages that it ignores like "folder deleted" but according to Dovecot https://www.dovecot.org/clients/ it implements IDLE correctly which is uncommon among clients. See https://wiki2.dovecot.org/Clients for more client quirks. The dovecot config file https://dovecot.org/doc/dovecot-example.conf has a imap_client_workarounds setting for many of these common bugs including "delay-newmail" which disables several of the unsolicited message types until the server is confident that the client is actually expecting to receive something.
In practise, in real life, clients get this wrong. That's all I'm trying to say.
Hacker News always has the well-actuallies but I'm pretty familiar with this and have implemented both an IMAP server and client. I'm not sure what you're trying to "correct" me about.
> HTTP as easy examples are simple blocking request-response
Well HTTP/1.1, HTTP/2 (and HTTP/3) surely not. You can make more request on a single channel and also the server can send you data you didn't requested (PUSH). Otherwise a modern site with a ton of resources would either take a minute to load or have to open 100 connections to the server.
MQTT is another example of protocol that works this way.
> "every" is just not true
Every protocol that was born after the 90s, let's rephrase it like that.
The issue was not making multiple requests on a single connection, but that IMAP can interleave and reorder responses. It's still not that hard, but it's a change.
HTTP/1.1 does not allow data you didn't request in random places. You need to specifically request a feed of server sent events. In every other instance you know that the response that come back will be replies to a request (in the case of SSE's, the reply will just keep coming as long as the server sends events), and in the same order as the requests. That means that a "dumb" client can just synchronously send requests and read the reply in a string request/response manner without worrying about getting something else back. Neither of those constraints hold for IMAP.
It's not independently difficult per se, it's just mismatched to the way that other protocols often work in a way that, in practise, few clients implement well. Most clients and libraries implement it as if it were request-response and as a result either produce wrong answers or are notably less efficient as you note.
> Every protocol works this way, nothing new.
No? POP3 and HTTP as easy examples are simple blocking request-response. Some do either pipelining or multiplexing with the command-tagging, but don't have unsolicited messages. I can think of only a few other comparable protocols with this paradigm but "every" is just not true.
> of course, otherwise how do you think notifications can work?
Yes? This is indeed _why_ it works this way. I don't know what you're correcting me about. It does this to implement notifications and liveness. We're agreeing.
> Never had any problem with Thunderbird
Thunderbird is one of the better implementers, yes. There are messages that it ignores like "folder deleted" but according to Dovecot https://www.dovecot.org/clients/ it implements IDLE correctly which is uncommon among clients. See https://wiki2.dovecot.org/Clients for more client quirks. The dovecot config file https://dovecot.org/doc/dovecot-example.conf has a imap_client_workarounds setting for many of these common bugs including "delay-newmail" which disables several of the unsolicited message types until the server is confident that the client is actually expecting to receive something.
In practise, in real life, clients get this wrong. That's all I'm trying to say.
Hacker News always has the well-actuallies but I'm pretty familiar with this and have implemented both an IMAP server and client. I'm not sure what you're trying to "correct" me about.