[occi-wg] ElasticHosts introduction

[Sam Johnston]

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> 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> 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
> > 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/d3afa02d/attachment.html