4 ms·

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, s

by e_y_ 4y ago

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.

Gigachad 4y ago
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.
- dale_glass 4y ago
  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.
  - Gigachad 4y ago
    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.
    - masklinn 4y ago
      That means a protocol can not evolve in time to integrate new needs of clients and / or servers.
      - Gigachad 4y ago
        It can, you bump the protocol version number and move on. Give some grace period of compatibility and then shut off the old version.
        masklinn 4y ago
        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.
        Gigachad 4y 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.

by e_y_ 4y ago

Gigachad 4y ago

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.

dale_glass 4y ago
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.
- Gigachad 4y ago
  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.
  - masklinn 4y ago
    That means a protocol can not evolve in time to integrate new needs of clients and / or servers.
    - Gigachad 4y ago
      It can, you bump the protocol version number and move on. Give some grace period of compatibility and then shut off the old version.
      - masklinn 4y ago
        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.
        Gigachad 4y 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.