tag:blogger.com,1999:blog-6170119.post112035137960833601..comments2023-11-02T02:59:37.932-06:00Comments on thrashor: thrashorhttp://www.blogger.com/profile/12208535828055935183noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6170119.post-1123196044637986452005-08-04T16:54:00.000-06:002005-08-04T16:54:00.000-06:00I've been arguing with the inventor of JSON himsel...I've been arguing with the inventor of JSON himself about an optional Javascript identifier at the front of a JSON construct, which could go a long way toward a more "self-describing" JSON. I've blogged on it, at first proposing it be called JSON++, but now I have another name in mind, and have completed my first stab at a parser, for Java.<BR/><BR/>In the meantime google on "JSON++" and you can find my blog post and the relevant usenet article. Feel free to contact me via email and/or don't be surprised if you hear from me when I unveil version 0.1.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6170119.post-1120540019024658902005-07-04T23:06:00.000-06:002005-07-04T23:06:00.000-06:00You have made a strong denfense of your design dec...You have made a strong denfense of your design decision to use JSON in place of XML in client-server communications. For example, libraries in North America are not well known for having high network capacity, so reducing the load on the wire is not a bad idea. My last remaining concern is whether the use of JSON instead of XML will be a barrier to interoperability and extensibility. What I mean is, there are thousands of tools and developers that understand XML, but far fewer that understand JSON. Now, it is not that JSON is hard to understand, parse, or otherwise work with, but I would love to see - in my lifetime - libraries that are compliant with standards in use outside the library world. I would not want JSON to be the next MARC or Z39.50. I agree 100% with <A HREF="http://www.kentongood.com/?p=76" REL="nofollow">Kenton Good</A> in this respect. However, I note that you say that you have built XML flavors of all of your JSON interfaces - will these be maintained throughout your development cycle.<BR/><BR/>I am a great champion of your efforts. In fact, I will state publically that I predict the success of this project will drive much needed innovation among the commercial ILS vendors. Increased choice and increased innovation will only be good for our libraries.<BR/><BR/>As for helping out - I would love to do a security review of your architecture and code base, if you are interested.<BR/><BR/>Cross posted <A HREF="http://open-ils.org/" REL="nofollow">here</A>.thrashorhttps://www.blogger.com/profile/12208535828055935183noreply@blogger.comtag:blogger.com,1999:blog-6170119.post-1120406250604619952005-07-03T09:57:00.000-06:002005-07-03T09:57:00.000-06:00While I understand your concerns, for I shared the...While I understand your concerns, for I shared them initially, I'll point out a couple things for you to consider:<BR/><BR/> * <I>How do you, and we, define "usablitiy"?</I><BR/>Open-ILS defines it as "the property of a project that allows work to get done in an efficient manner." Choosing an optimized wire protocol is part of that because the libraries in our consortium are on rather slow network connections. Our JSON base protocol is more than 50% smaller, sometimes as much as 90%, and the deserializer is significantly faster than an XML parser.<BR/><BR/> * <I>Use the right tool for the job</I><BR/> As a supporting argument to the point above, consider a pure Java application: one would write a JNI based app and then add a SOAP interface to it. Since the main client applications of the Open-ILS backend will be a XUL-based staff client and the DHTML based OPAC, <A HREF="http://json.org/" REL="nofollow">JSON</A> <B>is</B> the tool for the job.<BR/><BR/>That being said, here's a point which should allay your concerns. Since we've already written the XML version of everything we're doing in JSON, as far as data transfer is concerned, we are planning to add support back in to OpenSRF to allow you to choose which format you'd like the result of a method request to be returned.<BR/><BR/>One last thing about the "self describing" nature of XML: it's only self describing to humans, not to machines. With the possible exception of the "semantic web" uses of RDF, an application that uses XML as a messaging protocol can only understand and use tags that it has been told about using an XSD or similar authority document. This is <I>exactly</I> the same position we are in when using JSON, with the exception that you, as a human, need to look up the meaning of a field within a hinted structure. I'll <B>definitely</B> accept that one extra step of "indirect documentation" as the price for the measured gain in performance we've received.<BR/><BR/>Of course, the reason I'm posting this response isn't to fight over XML, or even, really, to defend our design decisions. These decisions are ours to live with, right or wrong. The <I>real</I> reason I am responding is that it's in the best interest of our project to reevaluate our design any time the opportunity arises. I'm very glad you started the discussion on JSON, since it forced me to double check our design and make sure we're moving in the right direction. We all thank you, sincerly, for the constructive sharp-stick-in-eye ;), and I, personnally, hope you'll continue to take enough interest in our project to question our design, and to contribute in other ways down the road.<BR/><BR/><BR/><I>Cross-posting this to <A HREF="http://open-ils.org/blog/?p=31#comments" REL="nofollow">our blog</A></I>Anonymousnoreply@blogger.com