Hacker News Reader

Comment by e_y_ | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com