Live data from Hacker News

Transit: JSON Data Interchange Format

github.com

31–40 of 124 posts

Re: Transit: JSON Data Interchange Format

#31
post #21

Earlier quoted context omitted.

My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?

I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays. And now with Schemas and editor support for them, I think it is an acceptable replacement personally.

Nodes for data, attributes for metadata.

I think you made a good argument, although I personally prefer the more mature XML tooling and metadata support for versioning.

Re: Transit: JSON Data Interchange Format

#32
post #11

Reinventing XML, one data type at a time.

My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?

JSON is pretty great to parse in a variety of (web-relevant) languages.

And it's a good data exchange format if you're okay with its loose typing.

But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…

Re: Transit: JSON Data Interchange Format

#34
post #20
post #18

Earlier quoted context omitted.

Hopefully something better than XML comes of it before the enterprise gets its grubby hands on it!

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Try creating that number is several languages.

#/usr/bin/python n = 1.0000000000000000000000000000001 print n # 1.0

//Javascript n = 1.0000000000000000000000000000001; console.log(n); // 1

Re: Transit: JSON Data Interchange Format

#35

The most novel use of transit is in the Sente [1] library for clojure/script. It is an abstraction over long-polling / websockets that lets us treat it as a core.async channel (which is like a go-block in Go). It's worked awesome for updates, and using Transit to keep the transmissions minimal has let us focus on the API for a realtime system. [1] - https://github.com/ptaoussanis/sente#sente-channel-sockets-f...

In a project I tried both chord and sente and settled on chord. Chord was much simpler.

It was a point to point system. Sente seemed to have better support for point to multipoint (like a chat app). It was overkill for what we were doing and chord fit the bill nicely.

https://github.com/jarohen/chord

Re: Transit: JSON Data Interchange Format

#36
post #30
post #29

Earlier quoted context omitted.

Then use this instead: { number: "1.0000000000000000000000000000001" } How is it worse than XML?

See: https://news.ycombinator.com/item?id=10385610

Ok, now I see that you are complaining that the JSON Schema language is not strong enough. In this case I think people should create better new schame languages for JSON, as I find that the JSON syntax is better suited to data than XML, which is better suited to marked up text. (maps, arrays and atomic literals are fundamental data concepts, while tags, attributes, free text are closer to mark-up. )

Re: Transit: JSON Data Interchange Format

#37
post #26
post #24

Earlier quoted context omitted.

Feel free to write a schema definition for json data (or use the existing). Why should this not be possible?

Well in this case, JSON schema doesn't specify any more fundamental types other than "number". On the receiving end of a wire or network contract, how do we pick a storage type for "number"? We can't because the constraints of the type are undefined. Ergo JSON schema isn't a strong schema language. Be explicit is really important when defining contracts. Type this in your address bar for an illustration: javascript:a…

On Firefox, the maximum number of digits that yield values different to 1 are:

javascript:alert(1.000000000000001);

Re: Transit: JSON Data Interchange Format

#38
post #36
post #30

Earlier quoted context omitted.

See: https://news.ycombinator.com/item?id=10385610

Ok, now I see that you are complaining that the JSON Schema language is not strong enough. In this case I think people should create better new schame languages for JSON, as I find that the JSON syntax is better suited to data than XML, which is better suited to marked up text. (maps, arrays and atomic literals are fundamental data concepts, while tags, attributes, free text are closer to mark-up. )

The thing with XML is it's actually much lower level. There are no types inferred by an XML document. It's literally just chunks of data. JSON defines strings, boolean, maps, arrays, numbers.

It's conceptually easier to think about JSON with simple data sets but it's terribly inflexible and you have to think about how things are represented inside strings. A couple of thought exercises on JSON:

1. How do you represent an image inside JSON?

2. How do you represent a reference to another part of the data in JSON (consider a DAG for example)?

3. How do you represent an ordered set or an unordered set in JSON?

4. How do you represent an unsigned value in JSON?

Re: Transit: JSON Data Interchange Format

#39
post #20

Earlier quoted context omitted.

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Try creating that number is several languages. #/usr/bin/python n = 1.0000000000000000000000000000001 print n # 1.0 //Javascript n = 1.0000000000000000000000000000001; console.log(n); // 1

  from decimal import Decimal
  n = Decimal("1.0000000000000000000000000000001")
just because float is the default, doesn't mean you have to use it. JSON doesn't have anything else, though.
Post reply on HN