Here we moved away from yaml (json was in its infancy when we opted for yaml). We now serialize values over the wire using Clojure expressions and nippy to get some compression and speed improvement. Nippy falls back to the reader if it does not know how to compress a given value.
We plan to migrate to 1.4 to extend the reader with our custom literals. JSON is not extensible as far as I know. The combination of nippy and reader custom literals look to me as a transparent way to integrate some value representations specific to our business domain without compromising on performance, extensibility and simplicity. Am I missing something ? Luc P. > which problem other than "NIH" is edn solving? - given it's a subset of > clojure's data notation, it's not really native clojure either, so you gotta > convert to/fro. > So: Why do we need another JSON? > > I'm sure you have answers to these questions, possibly answered them before, > but definitely not answered them on the edn page. > > Regards, > -Martin Weber > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
