With all due respect, I continue to disagree on the topic of using HTTP for data interchange.
Yes, an HTTP multipart response will accomplish the need for multiple named resources. The problem is that parsing of a multipart response isn't simple, and library support is weak across many languages. The widely adopted cURL library does not support multipart response parsing at all. JSON is widely adopted, human readable, and has parsing libraries available for every major language. There is a bit of additional bloat, but I believe it is warranted in this case because of the convenience and ease it brings to developers. If the idea is to "KISS", and provide a method that is both quick and easy to implement for the average developer, then JSON is a stand out option. Using HTTP for the data interchange will make things difficult for a lot of developers if multipart responses are used. JSON will be greeted with open arms. On 12/19/2011 9:09 AM, slush wrote: > I agree with Luke that HTTP standard has everything necessary and > bloating payload with json/xml is not necessary. > > Btw that argument "we have json in client already" seems pretty wrong, > because json in server rpc solves another problem (and solve it in wrong > way, because of data type issues, but it's another story). ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
