JSONObject is fine. I imagine that any development organization could use it in their project as long as their legal staff is willing to forgo the option of doing Evil. (That's what the license says ;-)
My point is that pulling in *any* third party code is always a bigger barrier to adoption to using something that's already built in to the environment and has been for many years, so it even works in organizations that have not yet adopted the latest releases of things. (With that said, having JSON support in Python 2.6 is a good thing and it's too bad that the Java platform is moving so slowly these days.) As others have said more eloquently, if need to ever support non-string data types, arrays, or nested structures, then JSON is the best choice, over XML or something hand-rolled. But if the need is to just handle a short list of single name-value pairs, then using form-urlencoded, to me, is the simplest choice that places the fewest barriers in front of developers on all platforms. *From:* Luke Shepard [mailto:lshep...@facebook.com] *Sent:* Friday, May 07, 2010 1:48 AM *To:* Greg Brail *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) On May 6, 2010, at 9:13 AM, Greg Brail wrote: I agree that JSON is the long-term winner. However, at least for Java and Python I know that JSON parsers are not part of the standard library, whereas everything needed to decode a url-formencoded library is in the standard libraries and has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the right library, but getting legal clearance if it's open source and you work for a big company. Python includes a JSON parser in Python 2.6: http://docs.python.org/library/json.html Java has JSONObject available. Are there cases where it would be difficult to use a library like this?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
