[ Full disclosure -- I'm using my personal address with Launchpad, etc., but I work for Rackspace. ]
On 12/04/2012, at 7:28 PM, Jorge Williams wrote: > Generally, I agree with a lot of what you're saying, but I want to point out > a couple of things: > > 1. Static language folks gravitate to XML, not simply because they're > invested in it, but because it solves a real problem: > […] > and I should see those errors at compile time or while I'm authoring my code > if a have a good editor or IDE....I shouldn't have to wait until my program > is run to catch those errors. > […] > but at that point, there's very little benefit to having a static language, > because I don't have the assurances and guarantees that the language > provides. So I don't see a lot of Java folks dealing with JSON in that > manner. Most devs will need to build a class before hand. So, you decrease > barriers for static language clients because there's a set of tools that can > extract the relevant info from XML schema languages and generate a set of > class files at compile time. There's nothing saying you can't do something > similar with JSON, but those sort of tools aren't there yet. Great -- I think it's good to level set here. We're talking about supporting an entire serialisation, all of its supporting code, the QA cycle, schema authoring, etc., and the #1 benefit is making the programming experience for a subset of our audience more comfortable. > 2. Then there's the issue of extensibility....especially distributed > extensibility. XML has that notion built in Heh; you mean bolted on with Namespaces in XML, and then completely messed up by XML Schema 1.0, then only partially fixed by 1.1. But yes. > JSON has no concept of it...and we are building extensible APIs. There are no > standard way in JSON to introduce a new property without guaranteeing that > there won't be clash. You've mention the need for namespaces in JSON > precisely to deal with this sort of issue > (http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json). First of all, as we've discussed many times, I don't think "extensibility" == "good" in all cases; if we allow/encourage too much extensibility, the platform we're building will fragment, and people won't see its full value. Extensions should be allowed where the make sense, not everywhere, and extensions should be encouraged to eventually converge. > In the absence of a standard method, we're been using prefixes, which has > worked out well, but most JSON tools don't know how to deal with them What does that *mean*? The prefix is an opaque part of the name -- what should a tool do with it? > and they seem alien to folk that are used to using JSON day to day. Perhaps, but doing something like RAX_FOO isn't that onerous. Or using a registry. Or just leaving it to the community to coordinate and document; try opening a shell, typing "set" and pondering how *that* name space is managed... > This is a big deal because dynamic language folks are more likely to deal > with the JSON directly...Static language folks are generally not dealing with > XML in the same way. In XML, the notion of extensibility is build into > parsers and data binding tools directly. Not really; it's a syntactic artefact of namespaces. I'd say that the tools manage it really, really badly, given how hard it is to author extensible schemas (and don't get me started on XML Schema). > Most folks don't have to worry too much about it. In fact extensible > protocols like XMPP and Atom Pub generally benefit from the extensibility > that's already built in: > http://metajack.im/2010/02/01/json-versus-xml-not-as-simple-as-you-think/ You bring up some interesting examples; XMPP and Atom are both products of the fashion for XML in the IETF in the early part of the 00's… we've learned a LOT since then, and there's a clear move towards more no-nonsense JSON in the APPS area more recently. The extensibility of both XMPP and Atom turned out to not really need that much coordination. Is extensibility important? Sure, but we've learned a LOT about it since XML and PEP; it shouldn't be slathered over your protocols and formats like peanut butter, but instead only exposed where it's genuinely needed. Is that a judgement call? Absolutely. > Given that, if we're going to go the route of just picking one format, I > think the fact that our API is extensible means that we might want to ask > ourselves whether XML isn't a better fit :-) I'm guessing you know I disagree with that by now. > Having said all of that, I realize that our devs are working in a dynamic > language, and don't see a lot of value in XML. It's important to take that > into consideration, but we should also be asking whether there's value to our > current clients and potential clients. Like it or not, there's a lot of > folks out there using static languages. Sure, but it's less clear they're spinning up VMs with them, or writing apps that talk to Swift. I'd really like to get some logging of User-Agents into Nova et al to help get these metrics (e.g., lib cloud produces a UA); see <https://bugs.launchpad.net/nova/+bug/975589>. > You're right in stating that if we had really good language bindings for Java > and .Net, then issue #1 would essentially go away -- especially if we had > language binding that was flexible enough to remove the need to go down to > the HTTP level. Also, if the language binding itself was extensible we could > also deal with issue 2. As things stand today though, I don't thing that we > are even remotely there yet. Sure. The question I'd ask, then, is it worth making our APIs seriously more complex, hard to develop, understand, maintain, test, document, etc. in the meantime, just to allow static language users to have their IDEs help them. Something that the dynamic folks have gotten pretty used to living without. Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
