Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transit: JSON Data Interchange Format

github.com

Post reply on HN
Print view View original

71–80 of 124 posts

Re: Transit: JSON Data Interchange Format

#71

Post by Skinney »

nly wrote: post #65

Not sure I like the idea of cramming ASCII type tags in to the encoded JSON. I'm more partial to the way Avro does it, where the encoded JSON remains type-tag and cruft free, and a separate schema (also JSON) is used (and required) to interpret the types, or encode to the correct binary encoding.

Transit also allows you to use msgpack, but JSON is more performant on the web.

Another feature Transit has is that it caches identical keys (can also cache values with some additional code), giving you a smaller footprint.

Re: Transit: JSON Data Interchange Format

#72

Post by Skinney »

hyperpallium wrote: post #62

> The extension mechanism is open, allowing programs using Transit to add new elements specific to their needs. Users of data formats without such facilities must rely on either schemas, convention, or context to convey elements not included in the base set, The extension mechanism is writing handlers in all languages communicated with, since its stated purpose is cross language value conveyance. In contrast, a schem…

Do you have an example of such a schema language?

Re: Transit: JSON Data Interchange Format

#73

Post by falcolas »

waxjar wrote: post #50
easytiger wrote: post #4

Earlier quoted context omitted.

It's the whole FAST/FIX clusterfuck all over again. Use a binary format and stop cocking around. You can't serialise/deserialise it faster and JSON is a string based mess. No low latency path can absorb it. Even influxdb have removed JSON support because it was their slowest part of their critical path that could not be optimised. Complete lack of mechanical sympathy + laziness is why JSON is popular outside of the w…

I don't think I would enjoy debugging a service that talks in a binary format.

That ship is at the edge of the harbor, sails raised, and helmed by HTTP2.0. Binary formats are becoming the default, not the exception.

Re: Transit: JSON Data Interchange Format

#75

Post by gioele »

lars512 wrote: post #10

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/7/22/transit JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. Stronger typing allows the optional use of a more compact binary form…

> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here.

XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

Re: Transit: JSON Data Interchange Format

#76

Post by nly »

Skinney wrote: post #71
nly wrote: post #65

Not sure I like the idea of cramming ASCII type tags in to the encoded JSON. I'm more partial to the way Avro does it, where the encoded JSON remains type-tag and cruft free, and a separate schema (also JSON) is used (and required) to interpret the types, or encode to the correct binary encoding.

Transit also allows you to use msgpack, but JSON is more performant on the web. Another feature Transit has is that it caches identical keys (can also cache values with some additional code), giving you a smaller footprint.

Sure, but all that comes at the huge disadvantage of throwing away the ability for someone to just grab a JSON library and access your data adhoc. Now you have to fiddle with stripping away tildes and cache references and such.

At the same time, I don't see how you can do anything sensible with Transit except throw it in to a hashmap/dict alongside runtime type information. This is natural for dynamic languages, but, without a schema, you're left to write you're still left to write your own error-prone structural validation, and can't fully leverage the efficiency of static languages. MsgPack has this problem as well.

Optimising the JSON representation just doesn't seem worth it to me. Avro for example encodes enums by exposing the type names as JSON keys. It sucks, and it's something I'd change, but at the end of the day you're building on a poor transport. Caching reminds me a lot of DNS label compression, or a poor mans preset zlib dictionary.

Re: Transit: JSON Data Interchange Format

#77

Post by calibraxis »

oskarth wrote: post #54
andyjohnson0 wrote: post #19

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?

The downvotes are because it comes across as a shallow, middlebrow dismissal. An interesting and useful criticism would first engage with the strongest arguments of Rich Hickey (creator of Transit and edn). If you find something in his Language of the System talk ( https://www.youtube.com/watch?v=ROor6_NGIWU ) that you either (a) disagree with (b) think XML solves already, I and many others would certainly be interes…

Transcript of that talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Re: Transit: JSON Data Interchange Format

#78

Post by zcdziura »

gioele wrote: post #75
lars512 wrote: post #10

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/7/22/transit JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. Stronger typing allows the optional use of a more compact binary form…

> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

History repeats itself, after all.

Re: Transit: JSON Data Interchange Format

#79

Post by brianberns »

gioele wrote: post #75
lars512 wrote: post #10

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/7/22/transit JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. Stronger typing allows the optional use of a more compact binary form…

> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

Yes, except that XML has a schema (XSD).
Post reply on HN