openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

On Apr 13, 2012, at 8:47 AM, Mark Nottingham wrote:

> [ 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. 
> 

There are a lot more clients than servers.  You have to weigh the cost of lowering barriers for those clients at the server side vs the cost of getting those client to successfully integrate with the system.  This is typically the a argument I make against SOAP and towards REST.  In static language circles creating a SOAP service is really, really  easy...but using soap typically introduces  high barriers to dynamic language folks.  Making the move from SOAP to REST definitely introduces some complexity on the dev side of the service in dev cycles, but you have to compare this cost against the cost that's saved on the client side and multiply that by the number of clients that benefit. 

Having said that,  I understand the cost of supporting a different media type is not insignificant, but it's also not rocket science. I reckon that the sate of XML support today may have to do more with the fact that our dev community doesn't see much value in XML, than in does with what it will actually takes to get it right....and like I said before, I can understand that perspective. 

> 
>> 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.

I totally agree, encouraging  convergence is important.

> 
>> 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?
> 

It messes up some of the syntactic sugar that folks are used to using:

server.name    vs   server["foo:name"]  


>> 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).
> 

That hasn't entirely been my experience.  For the most part you can set things up so you don't have to think much about namespaces.

>> 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. 

I reckon that not a lot of coordination was needed precisely because XML has built in extensibility. In it's absence, you have to adopt the namespace model that XML uses in JSON...that's generally perceived to be very unJSONic.  Or you have to build a system of coordination in.  I'm all for it though BTW.

> 
> 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. 


Sure.

> 
>> 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.
> 

Asking static language folks to just get used to not having compile time checks is silly. That said, I don't want to turn this into a static vs dynamic language debate.  I advocate just as hard for good JSON support when I'm dealing with static language folks....go talk to the atlas guys.

Again, I'm generally agreeing with what your article is saying.  If we had great/nontrivial static language binding support...that's extensible and flexible enough to remove the need to go down to the HTTP level, then there wouldn't be a need for this debate.

-jOrGe W.