[occi-wg] Unlocking the formats deadlock

[Sam Johnston]

On 5/25/09, Alexis Richardson <alexis.richardson at gmail.com> wrote:
> 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.

In so far as patents go they are... I can release a spec into the
public domain and still charge you royalties when you implement it,
and if you use my trademarked name to describe your implementation
then you're in trouble again.

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
>>
>