[occi-wg] ElasticHosts introduction

[Sam Johnston]

Actually you're spot on - I'm just pointing out what's common and conceding
that we should be flexible about the 1's and 0's.

Sam

On Thu, Apr 16, 2009 at 2:20 PM, <eprparadocs at gmail.com> wrote:

> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090416/3dac37ef/attachment.html