Hacker News Reader

Comment by Gigachad | Hacker News Reader

There is a lot of writings explaining that the reason open email clients largely suck / become unmaintained is that IMAP is extremely difficult to work with. It's not just the connection, you also have to parse and work with this custom protocol as well as deal with massive inefficiencies. Doing bulk actions like moving emails between folders requires massive amounts of requests rather than a single one describing the change.

JSON protocols have completely taken over the market because they are massively easier to deal with and trivially parse in to structs which don't require a 200 page document to detail the protocol.

View on HN

I've written multiple IMAP clients, and I agree it's a huge pain to work with. But the real issue is the API design and the fact that more advanced searching, synchronization, etc, is only available via extensions that are not guaranteed to exist on a given server.

You can write a JSON API that's equally bad, doesn't support paging, doesn't let you select just the fields you need, is missing key information in the extracted fields forcing you to parse the entire RFC822 text as a fallback, etc. Dealing with the parser is just one part of the battle.

Optional extensions pretty much signal the death of any protocol. It shows there is no longer any leadership or direction. Same thing happened to XMPP. A functioning and healthy protocol would just start with proposals and once they are well tested, bump the version number and list everything as mandatory. Then implementations can just say they will be dropping legacy_version in x months, update or become incompatible.

I think that would depend a lot on what the extensions contain. I think extensions are a decent idea when they're obscure functionality that would take a lot of work to implement.

Complexity has exploded as of late. It used to be a joke that programs grew until they became able to read mail. These days programs grow until they contain a web engine. It's not enough anymore to just have a chat window, the chat window has to generate thumbnails of webpages for you.

Something should either be in the protocol or not. No one likes a situation where you see a feature on your client and it sometimes works or sometimes doesn't depending on the situation.

We would be better off having a smaller selection of better software over 100 different email server implementations which can't agree on a basic set of features gmail had a decade ago.

That means a protocol can not evolve in time to integrate new needs of clients and / or servers.

It can, you bump the protocol version number and move on. Give some grace period of compatibility and then shut off the old version.

That's an optional extension by any other name.

You can't "give some grace period of compatibility" in an open / distributed ecosystem, every version of the protocol lives forever.

YAML's dumb fuzzy booleans still cause issues all the time even though Yaml 1.2 was released 13 years ago.

HTTP manages this pretty well. It's pretty common practice to turn off old http and TLS versions and things move along fine because the vast majority of users are on the latest version.

Most modern languages have a JSON encoder/decoder in their standard library too, making for one fewer dependency to worry about and that's never a bad thing.

Reply on news.ycombinator.com