[occi-wg] Unlocking the formats deadlock

[Alexis Richardson]

Sam,

On Mon, May 25, 2009 at 10:06 PM, Sam Johnston <samj at samj.net> wrote:
>
> By the way, CC licenses are useless to us without patent pledges.

Please can you explain this statement.  Not all CC licenses are the same.

alexis




> Sam on iPhone
>
>> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of
>> Sam Johnston
>> Sent: 25 May 2009 17:07
>> To: occi-wg at ogf.org
>> Subject: [occi-wg] Unlocking the formats deadlock
>>
>> Afternoon all,
>>
>> As you know I spent last week evangelising OCCI at the Cloud Computing Expo
>> in Prague (Monday/Tuesday) and Cloud Computing Expo in London
>> (Wednesday/Thursday), presenting the Introduction to the Open Cloud
>> Computing
>> Interface<http://docs.google.com/Present?docid=ddqm27m2_298fsf9mqdg>
>> presentation at both. I was only scheduled for Prague but the organisers
>> found a spot on the technical track in London too. I also ended up on the
>> panels at both which was even more opportunities to talk about cloud
>> interop. I'll be in Portugal for Cloud Views from Wednesday and will try to
>> get involved in OGF 26 time permitting as well. By now people certainly know
>> we exist and that we're doing real (hopefully good) work.
>>
>> Unfortunately we're somewhat stuck on the formats decision despite hours of
>> face to face discussion with 1/2 a dozen of the more active working group
>> members (myself, Alexis, Chris & Richard from ElasticHosts and the Fujitsu
>> guys). While this is not at all unusual for technical discussions we do need
>> to fairly urgently find a solution before people (myself included) lose
>> interest and wander off. I can't overstate how important this working group
>> is to the future of cloud computing and both of the alternatives are rather
>> unpalatable:
>>
>>  *   On one side we have Amazon EC2 APIs which are not only encumbered but
>> inelegant and inflexible (at least in the context of the enterprise use
>> cases I spend most of my time thinking about - no offense intended). Other
>> APIs designed to expose the functionality of a single implementation fall
>> into the same category and while they meet their specific needs well, we
>> need to expose the current and future functionality of all current and
>> future implementations, not just one today. At the extreme end of the
>> simplicity scale you have text-based APIs which we all now agree won't meet
>> our needs.
>>  *   At the other end of the scale we have VMware's vCloud API which has
>> been injected into the DMTF process, following in the footsteps of OVF. I
>> fully expect the resulting "open API" to be almost word-for-word identical
>> to the new VMware APIs which is something the
>> DIGISTAN<http://www.digistan.org/> guys call "vendor
>> capture<http://www.digistan.org/open-standard:definition>". Unlike the
>> public cloud APIs, this will be well-suited for enterprise and you can be
>> sure that service providers will deploy VMware en masse to provide it as
>> part of their [semi-]private "I can't believe it's not cloud" offerings.
>> Good on them for being first and forcing the rest of the industry to follow
>> their lead.
>> This working group's job is to find the middle ground - something which is
>> simple enough to be useful for public cloud offerings but extensible enough
>> to be useful for more challenging tasks (e.g. enterprise). This is also
>> critical for hybrid clouds (unless you're all happy to implement DMTF's APIs
>> in addition to your own). The business case is easily justified even if only
>> on the basis of getting access to customers who are currently kicking the
>> tyres with tactical deployments but unable to deploy strategically.
>>
>> As you know I have been pushing Atom[Pub] hard, perhaps too hard, and the
>> XML-xenophobes have dug their heels in as a result. It was made painfully
>> obvious in London that blanket application of AtomPub to the problem isn't
>> going to fly with at least one of them and to that end I've spent the
>> weekend working on paring it back where it's not absolutely necessary. I've
>> also purchased and read O'Reilly's RESTful Web
>> Services<http://oreilly.com/catalog/9780596529260/> book by Leonard
>> Richardson<http://www.crummy.com/> and Sam Ruby from cover to cover and am
>> largely sold on their concept of a Resource Oriented Architecture
>> (ROA)<http://www.infoq.com/resource/articles/richardson-ruby-restful-ws/en/resources/04.pdf>
>> - do read this sample chapter if you have time.
>>
>> Fortunately I think I've found a simple, elegant solution which obviates the
>> need for Atom (at least where collections are not required). I've captured
>> it in a series of 3 blog posts which I'll forward to the list for the sake
>> of convenience and the archives.
>>
>> Cheers,
>>
>> Sam
>> -------------------------------------------------------------
>> Intel Ireland Limited (Branch)
>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> Registered Number: E902934
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>