6 ms·

So, how long until everything is JSON-shit over port 80 and how long until port 80 is old news and only port 443 is used for anything and everything? I can't c

So, how long until everything is JSON-shit over port 80 and how long until port 80 is old news and only port 443 is used for anything and everything? I can't claim to be familiar with IMAP, but it can't be worse than this garbage that requires an HTTP client and a JSON parser. To process JSON, you must inspect every character, which is reason enough it's an awful ''format'' that only an ignorant could hold dear. Douglas Crockford brags about how smart he is for disallowing comments, but there's whitespace allowed everywhere. Let's not forget this asinine integer nonsense, because JavaScript lacks real integers. I'm sure most people think HTTP clients and JSON parsers are standard-library affairs, nowadays, though; let's just entirely ignore matters of licensing and whatnot. It's disgusting to see this as an IETF standard, but people have been complaining about how that moves along for decades; take a look at Google's robots.txt ''standard'' that doesn't do anything useful and effectively makes every existing file standard, rather than do much of anything worthwhile. The WWW and JavaScript are nothing more than a continuation of this worse-is-better filth that UNIX and C previously championed; decades ago, the IETF revised the RFC for the Finger protocol and warned about security, solely because some idiot wrote a shitty Finger server in C; now, we have useless and unnecessary standards such as this that only serve to further this next generation of idiocy. I wonder when all of this will finally collapse under its own weight.

jimbo1qaz 7y ago
Can you provide some actual arguments as to what's wrong with JSON? It's a text format that can be inspected by humans, unlike binary formats. (Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases).
- verisimilitudes 7y ago
  >Can you provide some actual arguments as to what's wrong with JSON? It's a wasteful, textual format derived from a programming language vomited forth in under a week. It has asinine integer characteristics for no good reason; it's not a random-access format; validating it is even more work; hash table keys that appear multiple times, instead of being in error, instead overwrite each other, defeating most any kind of optimization; it is thus wildly inefficient to manipulate, as manipulating it correctly in all cases requires full and comprehensive parsing with checking. It is an asinine ''format''. >It's a text format that can be inspected by humans, unlike binary formats. Even then, there are much better textual formats that could be used, but I'm of the opinion that numerical (binary) formats are strictly superior, especially as they're used increasingly often. It's better to have good tools that will provide a human-readable representation, rather than pretend a single, inefficient representation for both man and machine is somehow the best option. >(Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases). Computer programs written by anyone competent are built around edge cases; that's much of what any reliable program is, accounting for edge cases. To disregarded edge cases, of which there are many in JSON, speaks to me that you have little concern for writing software correctly, but I imagine you'd deny this, as who doesn't want to write correct software? Simply understand that using a format with so many edge cases and other defects as JSON is foolhardy for much of anything.
  - jsnell 7y ago
    > hash table keys that appear multiple times, instead of being in error, instead overwrite each other I don't think that's true. The behavior with multiple keys is not defined. A JSON reader can choose to do whatever it wants (error, use first, use last, use all, etc). An interoperable JSON writer should never output duplicate keys.
    - bmn__ 7y ago
      You won't believe what happened next: RFC 6902 comes along and explicitly prohibits multiple keys. Programmers want to reuse JSON parsers, but can't. This is not a good position to be in.
      - jsnell 7y ago
        RFC 6902 is not a standard for JSON, it's a standard for "JSON patch", which appears to be another data format layered on top of JSON. It has no descriptive power on JSON in general. The relevant RFC is 8259, which neither explicitly allows nor prohibits duplicate keys. Instead it says: > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. That isn't a prohibition on duplicate keys, it's just a warning on what will happen in practice if you try to do that.
        chrismorgan 7y ago
        JMAP explicitly requires I-JSON, which is RFC 7493, and restricts this exact case: > Objects in I-JSON messages MUST NOT have members with duplicate names.
        jsnell 7y ago
- rapsey 7y ago
  - Anything outside of int32 must be encoded and decoded as a float. Oh the bugs/crashes this has caused. - It is way too easy to change the schema and wreak havoc with downstream users. - Some libraries will encode empty strings as null for instance, some as empty strings. Some will have empty objects, some null. Switch some configuration, change your serializer, ORM or anything that touches your data. Everything will work perfectly in your code, but json output can change and you will again break your downstream users. If you are designing an API, use protocol buffers. Json maybe as an optional output/input to your service. Keep it as a discouraged dirty optional feature and you will save yourself a whole lot of debugging and time wasting.
- IshKebab 7y ago
  The problems with JSON are pretty obvious: * It's inefficient compared to schema-based formats like Protobuf - you have to encode key names again and again. * It's inefficient compared to binary equivalent formats like CBOR - both in space and speed. * It's less reliable than explicit schema-based formats because it can't be validated (yes I know about JSON-Schema, nobody uses it). You essentially end up with an implicit schema that everyone has to recreate themselves from the documentation - especially if using statically typed languages. * It's a pain to use from statically typed languages. You have to write the schema in your language, whereas with things like Protobuf it will generate the code for you. * It doesn't have a proper type for arbitrary binary data. Most people (but not all!) encode it as a base64 string which is not very efficient and not actually a different type to a string, so again you rely on the implicit schema. * Maps can only have strings as their key type. * Minor annoyance, but trailing commas would be nice! * Its number type is not well specified. E.g. does it support uint64? "Human readable" is overrated. CBOR and similar formats can easily be inspected by humans just by converting them to JSON. The Smile format even starts with a :) smilie as its magic number to make it easily recognisable. Would you recommend not using compression or encryption on HTTP requests because it stops them being human readable?
  - edoceo 7y ago
    I use json-schema. I hate it but, i use it.
- octorian 7y ago
  > (Maybe IMAP is a text format too, so this isn't an advantage inherently) Actually, IMAP is a binary format that looks like a text format. This distinction is extremely important when you want to make a reliable Email client. There are also multiple ways of encoding text within it, that you need to keep track of. Personally, I wish they used a structured binary encoding. This becomes especially important when data size efficiency actually matters. With something like protobuf, you can even have the parser for it generated for you. (However, I have worked with binary formats that are more loosely structured.) Of course I am a fan of well defined and strongly typed formats.
tenderfault 7y ago
google defined websocket protocol not long ago. We didn't actually need it. They did. With such a huge browser market share, all they crave for is information. All of it. And most of us (developers) embrace this flow because each and every "fault" they "discover" and use to create a new idiotic standard is an opportunity for us to profit. And we feed it. I don't need jmap, none of us do. They need it, so they wrote 200 pages of stupid, extremely complicated specs with the hope that it will gain traction and we'll start developing. They can't do it alone. They need us to embrace it. I won't and I hope none of you will. I hope this standard will die with a whimper. I am doing my best to keep my e-mails where they belong. Far away from browser. I use SMTP. There's nothing wrong with it. It works. I use MIME. There's nothing wrong with it. It works. I personally don't use IMAP. ODMR is all I actually need. But I configure and maintain IMAP servers. I see nothing wrong with it either. It works. What baffles me is cyrus project accepting this idiocy. I just hope it won't become the new deal and the others (dovecot et all) will stay away from it. Panic and fear can and will escalate the process. So how long until "everything is JSON"-shit will take over? I'm 40 years old and my bet is I will live to see it happening. This is actually scary. And not because json or hydras.
- isodude 7y ago
  I tend to agree with you, even so, if not for these moves we wouldn't have any change at all. Email is not a solved problem, we just have a lot of fixes that makes it sort of stable. If not else we get a competing extension to IMAP because someone does not want JMAP.
- microcolonel 7y ago
  To be honest, JSON is pretty reasonable. The parsing speeds are very good, the grammar is a lot simpler than SMTP/HTTP/IMAP, it actually has numeric and boolean types. It is no surprise to me that the two people here complaining that IMAP is somehow acceptable don't even use it. JMAP solves real problems inherent with IMAP, particularly on clients that are not suitable for local archiving of messages (hence, ODMR/POP is not an option), and where IMAP sends considerably more data than the client actually uses (making it slow). I don't like the use of JSON for local IPC, as is showing up in some systems, but for RPC over an unreliable network, JSON is more convenient than not. As for the use of HTTP, it's not ideal in my view, and I tend to think it's overused. The one argument though, is that it allows JMAP to go over port 443 to a host that has an existing https service on that port (since you likely have a reverse proxy, probably NGINX, as your listener anyway) without having to send a bespoke upgrade request, which defeats the simplicity benefits of a custom protocol, since you have to implement HTTP to do the upgrade.

jimbo1qaz 7y ago

Can you provide some actual arguments as to what's wrong with JSON? It's a text format that can be inspected by humans, unlike binary formats. (Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases).

verisimilitudes 7y ago
>Can you provide some actual arguments as to what's wrong with JSON? It's a wasteful, textual format derived from a programming language vomited forth in under a week. It has asinine integer characteristics for no good reason; it's not a random-access format; validating it is even more work; hash table keys that appear multiple times, instead of being in error, instead overwrite each other, defeating most any kind of optimization; it is thus wildly inefficient to manipulate, as manipulating it correctly in all cases requires full and comprehensive parsing with checking. It is an asinine ''format''. >It's a text format that can be inspected by humans, unlike binary formats. Even then, there are much better textual formats that could be used, but I'm of the opinion that numerical (binary) formats are strictly superior, especially as they're used increasingly often. It's better to have good tools that will provide a human-readable representation, rather than pretend a single, inefficient representation for both man and machine is somehow the best option. >(Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases). Computer programs written by anyone competent are built around edge cases; that's much of what any reliable program is, accounting for edge cases. To disregarded edge cases, of which there are many in JSON, speaks to me that you have little concern for writing software correctly, but I imagine you'd deny this, as who doesn't want to write correct software? Simply understand that using a format with so many edge cases and other defects as JSON is foolhardy for much of anything.
- jsnell 7y ago
  > hash table keys that appear multiple times, instead of being in error, instead overwrite each other I don't think that's true. The behavior with multiple keys is not defined. A JSON reader can choose to do whatever it wants (error, use first, use last, use all, etc). An interoperable JSON writer should never output duplicate keys.
  - bmn__ 7y ago
    You won't believe what happened next: RFC 6902 comes along and explicitly prohibits multiple keys. Programmers want to reuse JSON parsers, but can't. This is not a good position to be in.
    - jsnell 7y ago
      RFC 6902 is not a standard for JSON, it's a standard for "JSON patch", which appears to be another data format layered on top of JSON. It has no descriptive power on JSON in general. The relevant RFC is 8259, which neither explicitly allows nor prohibits duplicate keys. Instead it says: > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. That isn't a prohibition on duplicate keys, it's just a warning on what will happen in practice if you try to do that.
      - chrismorgan 7y ago
        JMAP explicitly requires I-JSON, which is RFC 7493, and restricts this exact case: > Objects in I-JSON messages MUST NOT have members with duplicate names.
        jsnell 7y ago
rapsey 7y ago
- Anything outside of int32 must be encoded and decoded as a float. Oh the bugs/crashes this has caused. - It is way too easy to change the schema and wreak havoc with downstream users. - Some libraries will encode empty strings as null for instance, some as empty strings. Some will have empty objects, some null. Switch some configuration, change your serializer, ORM or anything that touches your data. Everything will work perfectly in your code, but json output can change and you will again break your downstream users. If you are designing an API, use protocol buffers. Json maybe as an optional output/input to your service. Keep it as a discouraged dirty optional feature and you will save yourself a whole lot of debugging and time wasting.
IshKebab 7y ago
The problems with JSON are pretty obvious: * It's inefficient compared to schema-based formats like Protobuf - you have to encode key names again and again. * It's inefficient compared to binary equivalent formats like CBOR - both in space and speed. * It's less reliable than explicit schema-based formats because it can't be validated (yes I know about JSON-Schema, nobody uses it). You essentially end up with an implicit schema that everyone has to recreate themselves from the documentation - especially if using statically typed languages. * It's a pain to use from statically typed languages. You have to write the schema in your language, whereas with things like Protobuf it will generate the code for you. * It doesn't have a proper type for arbitrary binary data. Most people (but not all!) encode it as a base64 string which is not very efficient and not actually a different type to a string, so again you rely on the implicit schema. * Maps can only have strings as their key type. * Minor annoyance, but trailing commas would be nice! * Its number type is not well specified. E.g. does it support uint64? "Human readable" is overrated. CBOR and similar formats can easily be inspected by humans just by converting them to JSON. The Smile format even starts with a :) smilie as its magic number to make it easily recognisable. Would you recommend not using compression or encryption on HTTP requests because it stops them being human readable?
- edoceo 7y ago
  I use json-schema. I hate it but, i use it.
octorian 7y ago
> (Maybe IMAP is a text format too, so this isn't an advantage inherently) Actually, IMAP is a binary format that looks like a text format. This distinction is extremely important when you want to make a reliable Email client. There are also multiple ways of encoding text within it, that you need to keep track of. Personally, I wish they used a structured binary encoding. This becomes especially important when data size efficiency actually matters. With something like protobuf, you can even have the parser for it generated for you. (However, I have worked with binary formats that are more loosely structured.) Of course I am a fan of well defined and strongly typed formats.

tenderfault 7y ago

google defined websocket protocol not long ago. We didn't actually need it. They did. With such a huge browser market share, all they crave for is information. All of it. And most of us (developers) embrace this flow because each and every "fault" they "discover" and use to create a new idiotic standard is an opportunity for us to profit. And we feed it. I don't need jmap, none of us do. They need it, so they wrote 200 pages of stupid, extremely complicated specs with the hope that it will gain traction and we'll start developing. They can't do it alone. They need us to embrace it. I won't and I hope none of you will. I hope this standard will die with a whimper. I am doing my best to keep my e-mails where they belong. Far away from browser. I use SMTP. There's nothing wrong with it. It works. I use MIME. There's nothing wrong with it. It works. I personally don't use IMAP. ODMR is all I actually need. But I configure and maintain IMAP servers. I see nothing wrong with it either. It works. What baffles me is cyrus project accepting this idiocy. I just hope it won't become the new deal and the others (dovecot et all) will stay away from it. Panic and fear can and will escalate the process. So how long until "everything is JSON"-shit will take over? I'm 40 years old and my bet is I will live to see it happening. This is actually scary. And not because json or hydras.

isodude 7y ago
I tend to agree with you, even so, if not for these moves we wouldn't have any change at all. Email is not a solved problem, we just have a lot of fixes that makes it sort of stable. If not else we get a competing extension to IMAP because someone does not want JMAP.
microcolonel 7y ago
To be honest, JSON is pretty reasonable. The parsing speeds are very good, the grammar is a lot simpler than SMTP/HTTP/IMAP, it actually has numeric and boolean types. It is no surprise to me that the two people here complaining that IMAP is somehow acceptable don't even use it. JMAP solves real problems inherent with IMAP, particularly on clients that are not suitable for local archiving of messages (hence, ODMR/POP is not an option), and where IMAP sends considerably more data than the client actually uses (making it slow). I don't like the use of JSON for local IPC, as is showing up in some systems, but for RPC over an unreliable network, JSON is more convenient than not. As for the use of HTTP, it's not ideal in my view, and I tend to think it's overused. The one argument though, is that it allows JMAP to go over port 443 to a host that has an existing https service on that port (since you likely have a reverse proxy, probably NGINX, as your listener anyway) without having to send a bespoke upgrade request, which defeats the simplicity benefits of a custom protocol, since you have to implement HTTP to do the upgrade.