7 ms·

Yeah, what can't be fixed by shoveling JSON shit into HTTP instead of a dedicated protocol? JMAP was stupid when the Fastmail CEO or whoever was here pushing i

Yeah, what can't be fixed by shoveling JSON shit into HTTP instead of a dedicated protocol? JMAP was stupid when the Fastmail CEO or whoever was here pushing it, and it's still stupid.

ikt 4y ago
Why do you call JSON shit? It's incredibly useful and I use it all the time, am I missing something?
- shakna 4y ago
  JSON has a few rough points that make it frustrating to parse. Like for example, most values requiring open and ending tags, no trailing commas allowed (so you must either be lax and non-compliant or backtrack the parser on last element), and other similar edge cases. This results in making it extraordinarily easy to break most parsers in use, today. For example, to kill Python: n="$(python3 -c 'import math; import sys; sys.stdout.write(str(math.floor(sys.getrecursionlimit() - 4)))')" left="$(yes [ | head -n "$n" | tr -d '\n')" echo "$left" | python3 -c 'import json; print(json.loads(input()))' That's a less than 1000-character long object, that can explode. Whilst there are more robust parsers you can get for Python, it doesn't change the fact that generating bad JSON is _easy_. So when you're handling something like email, on a mobile device which may drop a partial connection, you need a hell of a lot of extra work to show the partial download, which might even be everything except the closing braces, or you have to discard the whole thing - which isn't kind to your user.
  - duskwuff 4y ago
    > JSON has a few rough points that make it frustrating to parse. Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format. The same goes for the use of HTTP. It may not be the ideal protocol for accessing mail, but everyone knows how to work with HTTP, and tools to interact with it are plentiful.
    - shakna 4y ago
      > Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format. The same could easily be said for mbox and maildir. These have been around forever, and if you have a library for JSON, you've probably got a library for those two, as well. But parsing them tends to be less error-intensive if you hit some kind of connection interruption. The complaint for JSON in JMAP tends to come down to - does it improve the current status quo?
      - duskwuff 4y ago
        > But parsing them tends to be less error-intensive if you hit some kind of connection interruption. Never heard of the ">From" problem? :) mbox has a well-documented escaping problem -- many tools which parse mbox files will mistake a line which begins with the word "from" for the start of a new message. As a result, many tools which generate mbox data will insert a ">" before the start of those lines, mangling the data slightly to prevent corruption. But that's besides the point. mbox/maildir are data storage formats, not network protocols. The corresponding network protocols (POP and IMAP) have their respective problems as well, though.
        shakna 4y ago
        JSON's not a network protocol, either. It's a data storage format, too. :p Yes, they all have problems. That's... Our industry. You pick and choose your problems. Hence why it's easy to point out rough edges in JSON, and it's easy with mbox or maildir, too.
        addicted 4y ago
        How well supported are mbox and maildir relative to JSON? Do you have multiple high quality implementations for supporting mbox or maildir in nearly every language and framework in active use today? If not, then they’re nothing like JSON.
- verisimilitudes 4y ago
  S-expressions are better, and something that sees so much usage should have a dedicated format. In a saner world, this work would already be done so that each protocol needn't define the octets on the line. Regardless, IMAP already exists. It's a diseased mind that takes a shitty programming language, JavaScript, and turns it into a shitty structured data format.
- Gigachad 4y ago
  No you aren't missing anything. Most HN users have some weird nostalgia about obsolete technology. Custom protocols and XML are good, JSON is bad because Facebook and Google use it to deliver adverts and it reminds them of Single Page Apps.
yyyk 4y ago
IMAP is an ancient behemoth in strong need of modernization. JMAP is the replacement we have. Could modernization have been done with a dedicated protocol? I guess so. But no one (including you) did the work to get it done, so JMAP it is.
- verisimilitudes 4y ago
  That's not the way this works. I needn't accept the WWW garbage graphomaniacs attempt to force upon others.
- masklinn 4y ago
  > Could modernization have been done with a dedicated protocol? I guess so. But probably not because it adds an other layer of friction and complexity to deployment, which doesn’t do much good to your odds. And it requires an entire additional ecosystem of inspection and protection capabilities to appear. Not to mention the parsing and serialisation of a bespoke protocol, and the risk of all the usual framing and escaping errors in the protocol. It also requires going to Iana for a port.
- denton-scratch 4y ago
  > so JMAP it is Except it isn't. As you say, IMAP could do with modernisation; JMAP isn't that, it's a replacement. If you want to replace a protocol that's in very widespread use, then your replacement needs to offer decisive benefits to operators and users, otherwise they won't switch. JMAP seems to offer benefits only to developers.
  - yyyk 4y ago
    >As you say, IMAP could do with modernisation In theory that's doable. In practice modernizing a protocol with extensions is though, since support ends up patchy. Especially when the big email providers have few reasons to make a documented, non-propriety extension. Why would they when they can instead push people to their propriety apps? It's definitely possible that JMAP doesn't catch on. In that case, we'll probably just keep languishing with non-modernised IMAP. The key is getting client support, especially in mobile (where there is a noticeable user benefit) and in open source software.
WesolyKubeczek 4y ago
(shrug) I could probably say about IMAP that it looks like it has been developed by hardcore Lisp fanboys. Boils down to someone’s yum being someone else’s yuck.
- brongondwana 4y ago
  Hey, I love IMAP. For all its faults it is pretty powerful and good. I've spent a lot of time on it, but the reasons that JMAP was developed still exist and are still valid :)
pjscott 4y ago
IMAP is a protocol that you can only love if you haven’t had to try to implement it. I say “try to” because there are so many incompatible almost-implementations that you will never actually implement IMAP. Replacing it with something more sane seems like a good use of time.
- verisimilitudes 4y ago
  I'd rather implement IMAP than HTTP, TLS, JSON, and whatever other shit is involved here. All of those points apply to the WWW more than anything else.
  - Gigachad 4y ago
    No one implements HTTP, JSON, and TLS. There are libraries for every single language imaginable. The more shared parts of the stack, the less wasted effort so you only have to implement the parts specific to sending and receiving email.
    - 1995mike 4y ago
      > No one implements HTTP, JSON, and TLS. > There are libraries for every single language imaginable. These statements are contradictory.
      - mlyle 4y ago
        Only if you're insistent on willfully misreading them. [no application protocol implementer] implements HTTP, JSON, and TLS [because there are well-worn implementations that can just be used for the purpose].
        1995mike 4y ago
        HTTP is a massive standard that takes thousands of man hours to implement. It's not something that "just exists" out there. I guess maybe the intent is that if you don't have Google writing your standard library you shouldn't even be able to check your mail. I'm not a huge fan of IMAP (I wrote a client implementation for IMAPv4 a long time ago) but it's ridiculous that using what amounts to "SMTP for hypertext" as a transport layer is now common practice.

Yeah, what can't be fixed by shoveling JSON shit into HTTP instead of a dedicated protocol? JMAP was stupid when the Fastmail CEO or whoever was here pushing it, and it's still stupid.

ikt 4y ago

Why do you call JSON shit? It's incredibly useful and I use it all the time, am I missing something?

shakna 4y ago
JSON has a few rough points that make it frustrating to parse. Like for example, most values requiring open and ending tags, no trailing commas allowed (so you must either be lax and non-compliant or backtrack the parser on last element), and other similar edge cases. This results in making it extraordinarily easy to break most parsers in use, today. For example, to kill Python: n="$(python3 -c 'import math; import sys; sys.stdout.write(str(math.floor(sys.getrecursionlimit() - 4)))')" left="$(yes [ | head -n "$n" | tr -d '\n')" echo "$left" | python3 -c 'import json; print(json.loads(input()))' That's a less than 1000-character long object, that can explode. Whilst there are more robust parsers you can get for Python, it doesn't change the fact that generating bad JSON is _easy_. So when you're handling something like email, on a mobile device which may drop a partial connection, you need a hell of a lot of extra work to show the partial download, which might even be everything except the closing braces, or you have to discard the whole thing - which isn't kind to your user.
- duskwuff 4y ago
  > JSON has a few rough points that make it frustrating to parse. Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format. The same goes for the use of HTTP. It may not be the ideal protocol for accessing mail, but everyone knows how to work with HTTP, and tools to interact with it are plentiful.
  - shakna 4y ago
    > Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format. The same could easily be said for mbox and maildir. These have been around forever, and if you have a library for JSON, you've probably got a library for those two, as well. But parsing them tends to be less error-intensive if you hit some kind of connection interruption. The complaint for JSON in JMAP tends to come down to - does it improve the current status quo?
    - duskwuff 4y ago
      > But parsing them tends to be less error-intensive if you hit some kind of connection interruption. Never heard of the ">From" problem? :) mbox has a well-documented escaping problem -- many tools which parse mbox files will mistake a line which begins with the word "from" for the start of a new message. As a result, many tools which generate mbox data will insert a ">" before the start of those lines, mangling the data slightly to prevent corruption. But that's besides the point. mbox/maildir are data storage formats, not network protocols. The corresponding network protocols (POP and IMAP) have their respective problems as well, though.
      - shakna 4y ago
        JSON's not a network protocol, either. It's a data storage format, too. :p Yes, they all have problems. That's... Our industry. You pick and choose your problems. Hence why it's easy to point out rough edges in JSON, and it's easy with mbox or maildir, too.
        addicted 4y ago
        How well supported are mbox and maildir relative to JSON? Do you have multiple high quality implementations for supporting mbox or maildir in nearly every language and framework in active use today? If not, then they’re nothing like JSON.
verisimilitudes 4y ago
S-expressions are better, and something that sees so much usage should have a dedicated format. In a saner world, this work would already be done so that each protocol needn't define the octets on the line. Regardless, IMAP already exists. It's a diseased mind that takes a shitty programming language, JavaScript, and turns it into a shitty structured data format.
Gigachad 4y ago
No you aren't missing anything. Most HN users have some weird nostalgia about obsolete technology. Custom protocols and XML are good, JSON is bad because Facebook and Google use it to deliver adverts and it reminds them of Single Page Apps.

yyyk 4y ago

IMAP is an ancient behemoth in strong need of modernization. JMAP is the replacement we have. Could modernization have been done with a dedicated protocol? I guess so. But no one (including you) did the work to get it done, so JMAP it is.

verisimilitudes 4y ago
That's not the way this works. I needn't accept the WWW garbage graphomaniacs attempt to force upon others.
masklinn 4y ago
> Could modernization have been done with a dedicated protocol? I guess so. But probably not because it adds an other layer of friction and complexity to deployment, which doesn’t do much good to your odds. And it requires an entire additional ecosystem of inspection and protection capabilities to appear. Not to mention the parsing and serialisation of a bespoke protocol, and the risk of all the usual framing and escaping errors in the protocol. It also requires going to Iana for a port.
denton-scratch 4y ago
> so JMAP it is Except it isn't. As you say, IMAP could do with modernisation; JMAP isn't that, it's a replacement. If you want to replace a protocol that's in very widespread use, then your replacement needs to offer decisive benefits to operators and users, otherwise they won't switch. JMAP seems to offer benefits only to developers.
- yyyk 4y ago
  >As you say, IMAP could do with modernisation In theory that's doable. In practice modernizing a protocol with extensions is though, since support ends up patchy. Especially when the big email providers have few reasons to make a documented, non-propriety extension. Why would they when they can instead push people to their propriety apps? It's definitely possible that JMAP doesn't catch on. In that case, we'll probably just keep languishing with non-modernised IMAP. The key is getting client support, especially in mobile (where there is a noticeable user benefit) and in open source software.

WesolyKubeczek 4y ago

(shrug) I could probably say about IMAP that it looks like it has been developed by hardcore Lisp fanboys. Boils down to someone’s yum being someone else’s yuck.

brongondwana 4y ago
Hey, I love IMAP. For all its faults it is pretty powerful and good. I've spent a lot of time on it, but the reasons that JMAP was developed still exist and are still valid :)

pjscott 4y ago

IMAP is a protocol that you can only love if you haven’t had to try to implement it. I say “try to” because there are so many incompatible almost-implementations that you will never actually implement IMAP. Replacing it with something more sane seems like a good use of time.

verisimilitudes 4y ago
I'd rather implement IMAP than HTTP, TLS, JSON, and whatever other shit is involved here. All of those points apply to the WWW more than anything else.
- Gigachad 4y ago
  No one implements HTTP, JSON, and TLS. There are libraries for every single language imaginable. The more shared parts of the stack, the less wasted effort so you only have to implement the parts specific to sending and receiving email.
  - 1995mike 4y ago
    > No one implements HTTP, JSON, and TLS. > There are libraries for every single language imaginable. These statements are contradictory.
    - mlyle 4y ago
      Only if you're insistent on willfully misreading them. [no application protocol implementer] implements HTTP, JSON, and TLS [because there are well-worn implementations that can just be used for the purpose].
      - 1995mike 4y ago
        HTTP is a massive standard that takes thousands of man hours to implement. It's not something that "just exists" out there. I guess maybe the intent is that if you don't have Google writing your standard library you shouldn't even be able to check your mail. I'm not a huge fan of IMAP (I wrote a client implementation for IMAPv4 a long time ago) but it's ridiculous that using what amounts to "SMTP for hypertext" as a transport layer is now common practice.