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
I like the approach of smartly finding the middle ground! ☺ One of your posts had a comment stating that there were a fair number of standards efforts 1. Cloud Computing Interoperability Forum – AE: defines RDF for enomaly and EC2, implements a proxy pattern to these services 2. Open Grid Forum (OGF) Open Cloud Computing Interface Working Group; AE: Us! ☺ 3. DMTF Open Cloud Standards Incubator – AE: seems to be forming around OVF 4. GoGrid API (CC licensed) – AE: Evaluate? 5. Sun Cloud API (CC licensed) – AE: Evaluate? 6. Amazon Web Services as “de-facto” (i.e. as Euc. and Nimbus have proceeded). – AE:public but closed API If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what 4 and 5 offer and do not offer? See where our efforts here could improve these published APIs and models? Andy From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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.
On 5/25/09, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
I like the approach of smartly finding the middle ground! ☺ One of your posts had a comment stating that there were a fair number of standards efforts
1. Cloud Computing Interoperability Forum – AE: defines RDF for enomaly and EC2, implements a proxy pattern to these services 2. Open Grid Forum (OGF) Open Cloud Computing Interface Working Group; AE: Us! ☺ 3. DMTF Open Cloud Standards Incubator – AE: seems to be forming around OVF 4. GoGrid API (CC licensed) – AE: Evaluate? 5. Sun Cloud API (CC licensed) – AE: Evaluate? 6. Amazon Web Services as “de-facto” (i.e. as Euc. and Nimbus have proceeded). – AE:public but closed API
If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what 4 and 5 offer and do not offer? See where our efforts here could improve these published APIs and models?
I've done that myself already but you're welcome to go through the exercise yourself. By my clock you've got less than an hour until you miss our first deadline. By the way, CC licenses are useless to us without patent pledges. Sam on iPhone
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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.
Sam, On Mon, May 25, 2009 at 10:06 PM, Sam Johnston <samj@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On 5/25/09, Alexis Richardson <alexis.richardson@gmail.com> wrote:
Sam,
On Mon, May 25, 2009 at 10:06 PM, Sam Johnston <samj@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Tue, May 26, 2009 at 2:38 AM, Sam Johnston <samj@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,
Inasmuch as this is an issue, it is not unique to CC. IETF is open to the same commentary. For example TCP has no explicit patent grants afaik. Indeed TCP is IETF licensed, and the IETF license makes no explicit patent grants.
and if you use my trademarked name to describe your implementation then you're in trouble again.
I don't think this is an issue qua licenses such as CC-BY-SA which require attribution. If a license *requires* attribution (or similar) then attribution won't suffice to constitute trademark infringement. Note that this is a different case from that where attribution is not required.
Sam on iPhone
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Tue, May 26, 2009 at 9:37 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
On Tue, May 26, 2009 at 2:38 AM, Sam Johnston <samj@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,
Inasmuch as this is an issue, it is not unique to CC. IETF is open to the same commentary.
For example TCP has no explicit patent grants afaik. Indeed TCP is IETF licensed, and the IETF license makes no explicit patent grants.
I assure you that it is not possible/interesting/sensible for us to incorporate non-obvious<http://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness>content and/or concepts from existing standards without explicit patent waivers/grants/pledges. In fact even a patent pledge may not go far enough if it is tied to a particular standard (as is often the case - including for GData <http://code.google.com/apis/gdata/patent-license.html> as it turns out). Even things like function names can end up in patents so we owe it to our users to tread very carefully here.
and if you use my trademarked name to describe your implementation then you're in trouble again.
I don't think this is an issue qua licenses such as CC-BY-SA which require attribution. If a license *requires* attribution (or similar) then attribution won't suffice to constitute trademark infringement. Note that this is a different case from that where attribution is not required.
Attribution is something else again - I'm talking about things like Eucalyptus claiming to support the Amazon EC2 API despite the existence of at least one registered trademark<http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=77054011>for same. There is some room to move here (for example, Audi referring to BMW... only to result in a hilarious epic fail<http://www.37signals.com/svn/posts/1675-santa-monica-bmws-checkmate>) and we have our own name (OCCI) but if I were a competitor to Sun or Amazon I'd be very careful about including their names in my product marketing material. Sam
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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/resourc...
- 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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Sam, If the IETF are happy with it, then I am. a On Tue, May 26, 2009 at 9:52 AM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 26, 2009 at 9:37 AM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
On Tue, May 26, 2009 at 2:38 AM, Sam Johnston <samj@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,
Inasmuch as this is an issue, it is not unique to CC. IETF is open to the same commentary.
For example TCP has no explicit patent grants afaik. Indeed TCP is IETF licensed, and the IETF license makes no explicit patent grants.
I assure you that it is not possible/interesting/sensible for us to incorporate non-obvious content and/or concepts from existing standards without explicit patent waivers/grants/pledges. In fact even a patent pledge may not go far enough if it is tied to a particular standard (as is often the case - including for GData as it turns out). Even things like function names can end up in patents so we owe it to our users to tread very carefully here.
and if you use my trademarked name to describe your implementation then you're in trouble again.
I don't think this is an issue qua licenses such as CC-BY-SA which require attribution. If a license *requires* attribution (or similar) then attribution won't suffice to constitute trademark infringement. Note that this is a different case from that where attribution is not required.
Attribution is something else again - I'm talking about things like Eucalyptus claiming to support the Amazon EC2 API despite the existence of at least one registered trademark for same. There is some room to move here (for example, Audi referring to BMW... only to result in a hilarious epic fail) and we have our own name (OCCI) but if I were a competitor to Sun or Amazon I'd be very careful about including their names in my product marketing material.
Sam
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Tue, May 26, 2009 at 11:01 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote: If the IETF are happy with it, then I am. I hate to be the one to break it to you but even RAND is completely and utterly incompatible with your business model <http://www.rabbitmq.com/> as well as those of many of the participants on this list. Are you sure AMQP doesn't tread on any patents, possibly "conveniently overlooked" by your competitors? Need I remind you of the OpenSEMP debacle at the CCIF goat rodeo? The patents that litter the IP wasteland are like land mines - if we fail to exercise our duty of care to our users and end up stepping on one then the licensing fees will be determined by lawsuits, not "reasonable and non-descriminatory" fees (which typically only apply to large scale standards like MP3). I'm surprised this topic was deemed worthy of discussion... if we were doing something hard like standardising autonomic scaling algorithms then fair enough, but we're not. Sam
Sam, Since you mention AMQP, yes the whole thing is based on patent grants royalty free, from inventors, to implementers and users. This is similar to but stronger than how the W3C deals with patent grants (which I take it is why you bring up RAND). So I am not sure what your point is about having a business model that is incompatible with something. Nonetheless it is not at all obvious to me why the IETF is not a perfectly good model for internet protocols. And the IETF license is very explicit about patent grants not being made. In any case, the issue of which licensed works the OGF may derive work from, is a question for the OGF. alexis On Tue, May 26, 2009 at 10:39 AM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 26, 2009 at 11:01 AM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
If the IETF are happy with it, then I am.
I hate to be the one to break it to you but even RAND is completely and utterly incompatible with your business model as well as those of many of the participants on this list. Are you sure AMQP doesn't tread on any patents, possibly "conveniently overlooked" by your competitors? Need I remind you of the OpenSEMP debacle at the CCIF goat rodeo?
The patents that litter the IP wasteland are like land mines - if we fail to exercise our duty of care to our users and end up stepping on one then the licensing fees will be determined by lawsuits, not "reasonable and non-descriminatory" fees (which typically only apply to large scale standards like MP3).
I'm surprised this topic was deemed worthy of discussion... if we were doing something hard like standardising autonomic scaling algorithms then fair enough, but we're not.
Sam
On Tue, May 26, 2009 at 12:02 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
In any case, the issue of which licensed works the OGF may derive work from, is a question for the OGF.
Just because OGF permits something does not mean that we should to do it, especially if detrimental to our users. I'm not going to waste any more cycles on this discussion - anything other than RF is patent nonsense (so to speak). Sam On Tue, May 26, 2009 at 10:39 AM, Sam Johnston <samj@samj.net> wrote:
On Tue, May 26, 2009 at 11:01 AM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
If the IETF are happy with it, then I am.
I hate to be the one to break it to you but even RAND is completely and utterly incompatible with your business model as well as those of many of the participants on this list. Are you sure AMQP doesn't tread on any patents, possibly "conveniently overlooked" by your competitors? Need I remind you of the OpenSEMP debacle at the CCIF goat rodeo?
The patents that litter the IP wasteland are like land mines - if we fail to exercise our duty of care to our users and end up stepping on one then the licensing fees will be determined by lawsuits, not "reasonable and non-descriminatory" fees (which typically only apply to large scale standards like MP3).
I'm surprised this topic was deemed worthy of discussion... if we were doing something hard like standardising autonomic scaling algorithms then fair enough, but we're not.
Sam
Quoting [Sam Johnston] (May 25 2009):
5. Sun Cloud API (CC licensed) ??? AE: Evaluate? 6. Amazon Web Services as ???de-facto??? (i.e. as Euc. and Nimbus have proceeded). ??? AE:public but closed API
If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what 4 and 5 offer and do not offer? See where our efforts here could improve these published APIs and models?
I've done that myself already but you're welcome to go through the exercise yourself. By my clock you've got less than an hour until you miss our first deadline.
By the way, CC licenses are useless to us without patent pledges.
Please note that OGF sees it as its task to gain such pledges, if the group determines that this is required for the standard to be implementable under "Reasonable and Non-Discriminatory" license terms. For details, see http://www.ogf.org/About/abt_policies.php, and http://www.ogf.org/About/abt_policies_ipr.php for pledges covering OGSI and OGSA. "Where the Open Grid Forum knows of rights, or claimed rights, the Open Grid Forum Secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the Open Grid Forum of the relevant Open Grid Forum document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms." Hth, Andre.
Sam on iPhone
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
What is the definition "reasonable" in terms of licensing ? What are the hard costs ? Patent licensing can be a significant obstacle to adoption. Do you want students and universities sued for using OCCI technology ? Do you want to pay someone else for the work you did here ? Does your companies want to pay a competitor for your contributions here ? Look below to see what others considered "reasonable". The OMA DRM (a standards like body) charged $.35 per device with a $566,000 cap. Intertrust another DRM scheme is $3.5m annually and $325,000 per carrier. M$ graces us with only $2.9million and $625,000 per year for carriers. Look at MP3 licensing rates from Thompson: BTW, this means EVERYONE providing an open source mp3 player can be prosecuted and sued for up to $15,000 and $5.00 per copy download plus damages. In other places on their website, Thompson demands 3% of "associated" gross revenue from distributing content with an mp3 format. Here is the web site for all of you that want to pay a fee for each mp3 player you have: http://www.mp3licensing.com/royalty/ This is pricing from Thompson's public web site: -gary Andre Merzky wrote:
Quoting [Sam Johnston] (May 25 2009):
5. Sun Cloud API (CC licensed) ??? AE: Evaluate? 6. Amazon Web Services as ???de-facto??? (i.e. as Euc. and Nimbus have proceeded). ??? AE:public but closed API
If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what 4 and 5 offer and do not offer? See where our efforts here could improve these published APIs and models?
I've done that myself already but you're welcome to go through the exercise yourself. By my clock you've got less than an hour until you miss our first deadline.
By the way, CC licenses are useless to us without patent pledges.
Please note that OGF sees it as its task to gain such pledges, if the group determines that this is required for the standard to be implementable under "Reasonable and Non-Discriminatory" license terms.
For details, see http://www.ogf.org/About/abt_policies.php, and http://www.ogf.org/About/abt_policies_ipr.php for pledges covering OGSI and OGSA.
"Where the Open Grid Forum knows of rights, or claimed rights, the Open Grid Forum Secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the Open Grid Forum of the relevant Open Grid Forum document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms."
Hth, Andre.
Sam on iPhone
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Guys, One religious war is already one too many so let's not venture into RAND vs RF territory as well... IETF policy (foolishly IMO) neither restricts nor discourages RAND<http://news.cnet.com/Standards-group-beats-back-patent-foes/2100-1013_3-996351.html>as well but you don't see implementors being taxed for implementing HTTP now, do you. It's no surprise that such policies exist given the makeup of these groups but that doesn't mean we need to pander to them. Thanks Gary for explaining clearly why RAND is simply not going to happen for OCCI (fortunately we don't need it anyway). Sam On Tue, May 26, 2009 at 5:59 AM, Gary Mazz <garymazzaferro@gmail.com> wrote:
What is the definition "reasonable" in terms of licensing ? What are the hard costs ?
Patent licensing can be a significant obstacle to adoption.
Do you want students and universities sued for using OCCI technology ? Do you want to pay someone else for the work you did here ? Does your companies want to pay a competitor for your contributions here ?
Look below to see what others considered "reasonable".
The OMA DRM (a standards like body) charged $.35 per device with a $566,000 cap. Intertrust another DRM scheme is $3.5m annually and $325,000 per carrier. M$ graces us with only $2.9million and $625,000 per year for carriers.
Look at MP3 licensing rates from Thompson:
BTW, this means EVERYONE providing an open source mp3 player can be prosecuted and sued for up to $15,000 and $5.00 per copy download plus damages.
In other places on their website, Thompson demands 3% of "associated" gross revenue from distributing content with an mp3 format.
Here is the web site for all of you that want to pay a fee for each mp3 player you have: http://www.mp3licensing.com/royalty/
This is pricing from Thompson's public web site:
-gary
Andre Merzky wrote:
Quoting [Sam Johnston] (May 25 2009):
5. Sun Cloud API (CC licensed) ??? AE: Evaluate?
6. Amazon Web Services as ???de-facto??? (i.e. as Euc. and Nimbus have proceeded). ??? AE:public but closed API
If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what 4 and 5 offer and do not offer? See where our efforts here could improve these published APIs and models?
I've done that myself already but you're welcome to go through the exercise yourself. By my clock you've got less than an hour until you miss our first deadline.
By the way, CC licenses are useless to us without patent pledges.
Please note that OGF sees it as its task to gain such pledges, if the group determines that this is required for the standard to be implementable under "Reasonable and Non-Discriminatory" license terms.
For details, see http://www.ogf.org/About/abt_policies.php, and http://www.ogf.org/About/abt_policies_ipr.php for pledges covering OGSI and OGSA.
"Where the Open Grid Forum knows of rights, or claimed rights, the Open Grid Forum Secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the Open Grid Forum of the relevant Open Grid Forum document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms."
Hth, Andre.
Sam on iPhone
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 May 2009 17:07 To: occi-wg@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/resourc...
- 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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (5)
-
Alexis Richardson -
Andre Merzky -
Edmonds, AndrewX -
Gary Mazz -
Sam Johnston