[occi-wg] ElasticHosts introduction

[eprparadocs at gmail.com]

Sam,

 Perhaps I didn't quite understand your approach. I would think we
should enumerate the parts of each API and the interpretation and leave
to another section the actual bits over the wire. That way we could
support anything, including binary XML!

Chuck

Sam Johnston wrote:
> Ok so basically the request syntax (e.g. URLs, HTTP verbs) will be
> common, as well as the attributes and actuators (e.g. start, stop, restart).
> 
> I don't have a problem with supporting the most brain dead of clients
> (after all, I wrote the cush <http://code.google.com/p/cush/> cloud
> computing shell a while back with this in mind), but I'd like to keep
> some middle ground (e.g. for web interfaces like Q-Layer, so JSON?) and
> support unfettered extension for handling advanced functionality like
> billing and reporting, SLAs, security management, transparent embedding
> of supporting formats like OVF (all of which requires the additional
> flexibility of XML).
> 
> Sam
> 
> On Thu, Apr 16, 2009 at 1:53 PM, <eprparadocs at gmail.com
> <mailto:eprparadocs at gmail.com>> wrote:
> 
>     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 at samj.net <mailto:samj at 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 at ogf.org <mailto:occi-wg at ogf.org>
>     > http://www.ogf.org/mailman/listinfo/occi-wg
> 
>