[occi-wg] On repainting the bikeshed at the 11th hour...

[Sam Johnston]

On 5/8/09, Tim Bray <Tim.Bray at sun.com> wrote:
> On May 7, 2009, at 6:21 AM, Sam Johnston wrote:
>
>>> I'd like to hear more about why Sun moved off XML onto JSON.
>>
>> Q-Layer was always JSON wasn't it?
>
> I've already stated that Q-layer was not the issue.  Our cloud-storage
> implementation came first, long before we acquired Q-layer.  The
> initial implementation of the storage service was in JAX-B which gives
> you both XML and JSON for free.  We have a lot of people with net-
> protocol experience in the shop, and we just don't buy into this
> multiple-formats thing; it adds complexity, loses clarity, and isn't
> how the Internet or the Web work.  So we decided to go with just JSON,
> and the code I'm personally writing (Ruby interface to the q-layer
> back-end) is JSON-only and will stay that way.

Ok so I don't expect to see a cron job talking XML just as I don't
expect to see management software using plain text. Perhaps it's
marginally more convenient for web developers to get a JSON
serialisation rather than having to fire up parser objects too but
these are very different use cases that can be trivially supported in
a mechanical, cross-platform fashion by basing on XML. If they didn't
exist then JSON may well be a more interesting option for us, but they
do and we're happy to support them.

Your opinion about choosing one format and sticking with it is
understandable, but is not necessarily shared by everyone. The web
does have content negotiation and it is used... if you can then why
not? It's another potential differentiator and it need not impact
interoperability if done properly.

> Why JSON?  Because all our data elements are numbers or short chunks
> of text, do not involve fancy formatting, and fit naturally into lists
> and dicts.  Nesting is non-zero but also not deep (a data center has
> clusters, clusters have machines).  JSON had everything we needed and
> nothing we didn't need.  Plain text makes the nesting hard.  XML is
> overkill.

Sure, for your requirements. We do need to be more flexible in order
to deliver interoperability without stifling innovation as well as
playing nice with others (like SNIA who will be joining us on next
week's call and wantingto hear about potential integration points).

Thanks for your continued interest/input - it's great to see such
passionate discussion ongoing, and the vast majority of it is useful.
I'm going to have to get some shut eye...

Sam on iPhone

Sam