Live data from Hacker News

Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

github.com

171–174 of 174 posts

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#171

Earlier quoted context omitted.

One significant advantage is you can opt-in to sharing schemas - without requiring all consumers to have your schema. Like a lot of Amazon's internal data formats, Ion designed to support backwards compatible schemas as well (that is, adding additional fields does not break existing consumers). It has isomorphic text and binary representations as part of the standard making debugging or optimized transport a config o…

> without requiring all consumers to have your schema Then how is the client supposed to handle the data? Guessing? > backwards compatible schemas > text and binary representations > type system > maps well to several languages Protos have all these. > S-Expressions Okay? Is that useful?

>> S-Expressions >>Okay? Is that useful

Yes, super useful. Depends on how your application needs to use S-expressions. You could define DSLs for a very expressive and complex rules-engine with S-Expressions forming your rules. Now you can write your rules as text, pass it around and build rule evaluators of those expressions all on top of Ion.

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#173
post #154

Things I dislike about Ion, having used it while at Amazon: - IonValues are mutable by default. I saw bugs where cached IonValues were accidentally changed, which is easy to do: IonSequence.extract clears the sequence [1], adding an IonValue to a container mutates the value (!) [2], etc. - IonValues are not thread-safe [3]. You can call makeReadOnly() to make them immutable, but then you'll be calling clone since doi…

This is a good critique. Have you found anything better?

Re: Amazon open-sources Ion – a binary and text interchangable, typed JSON-superset

#174
post #131

Earlier quoted context omitted.

Do you mean passing around binary between backend services and then having a binary->JSON "proxy" behind whatever is receiving AJAX requests from the client?

My idea was that the client (HTML+JS) will transform the binary data into JSON or skip the conversion and process it directly. Seeing how fast JS engines have become and the amount of typed binary arrays processed in JavaScript, I believe it's a viable approach. But I'm not a frontend dev, so I can't be certain.

Sounds a lot like the ActionScript compiler, which compiled their EcmaScript-style scripting language into bytecode for the Flash runtime.
Post reply on HN