On 5/8/09, Benjamin Black <b@b3k.us> wrote:
On Thu, May 7, 2009 at 3:45 PM, Sam Johnston <samj@samj.net> wrote:
We were talking before about all URLs appearing in the protocol, which does make a lot of sense. UUIDs are universally unique already are resolveable if not retrievable from the entry point that served them, and don't break when moved or shared. There are pros and cons of both approaches bit I think we need to understand the full implications before we decide one way or the other.
Can you point me to the requirements you've written up for this?
The requirement to link compute, storage and network resources together is obvious is it not? Our requirements for migrating and shared resources are obvious too but could probably afford to be committe to digital ink if they're not already in the wiki.
There have (unsurprisingly) been public and private calls to rubber
stamp various APIs but each have their benefits and drawbacks and we're trying to pick out the best parts. Single entry points, discovery, controllers and some of the structure came from Sun^W Oracle Cloud APIs already... the main thing that hasn't (yet) come across is JSON.
Please refrain from putting words in my mouth. I am not asking that work be rubber stamped, I am asking that work be adopted as a basis for further work, rather than recreating large portions of it. Once again, the question goes unanswered.
Ok so the attributes will be reviewed against our registry before long... already things like "operating system" will likely be added. The virtual datacenter structure for both Sun and VMware is too rigid for my liking and I'm hoping categories and tags can cover this requirement adequately and flexibly. Aside from that we've already taken a good deal of inspiration from this source and tim's excellent blog post on the subject. Was there something else you wanted us to take on board? Sam on iPhone