Having implemented "cloud storage" in SOAP, XMLRPC, JSON and even Sun RPC I can see no specific benefit to preferring one over another except for pure performance (if that is an issue). Certainly the amount of code to handle one over another is pretty minuscule now a days. I think the approach Sam has taken, very agnostic, is the right approach. Chuck Wegrzyn Twisted Storage Chris Webb wrote:
Sam Johnston <samj@samj.net> writes:
Tim Bray (who we'd very > much like to see get on board) says<http://twitter.com/timbray/statuses/1396042066>he " *Really [doesn't] like the JSON-*or*-XML trend. Adds work, no benefit, pick 1*". Perhaps the answer is to require one and provide for others.
Having implemented a cloud infrastructure platform with support for several data formats, I dispute his claim with evidence! We originally supported only the simple text/plain KEY VALUE format in our API. Here is the diffstat from our infrastructure code for the changeset that implemented JSON:
$ hg export 7c87001589f5 | diffstat bin/apiserver | 50 +++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-)
As you can see, it's a microscopic amount of extra code. I expect an even smaller diff to be required to add XML. (Nobody's asked for it yet, so we've prioritised other development: all our test users seemed to prefer plaintext or JSON at present.)
Of course, it's only easy for us because we have designed our API to be so simple and direct without excessive abstraction...
Cheers,
Chris. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg