Ok so to further explain this requirement, early versions of the spec talked about dumping similar resources into buckets or "collections" - e.g. /compute, /storage, /network. The problem is that the web today doesn't tell you that images need to live in /images (even if they often do). Once you add the type of resource to its metadata you no longer need to encode it into the URL (which is fugly btw, and not particularly RESTful) and the result is that users have much more freedom as to how they lay out their resources.

Unfortunately many APIs restrict you to certain (generally legacy) terminology like "virtual data centers" and "virtual racks" which is something I very much wanted to avoid - even if only to be able to cater for the various perspectives on this issue rather than (unsuccessfully) trying to force our view down everyone's throats.

That is to say that said URLs are informative rather than normative, and perhaps even belong in the walkthrough. I was thinking more along the lines of:

http://cloud.example.com/us-east/webapp/web02

For a burnt-in hypervisor this might be simply:

http://node01/web01

Sam

On Fri, Oct 9, 2009 at 5:33 AM, Michael Behrens <michael.behrens@r2ad.com> wrote:
For paragraph 2.2 Basics, under the URL Namespace paragraph, is this the sort of
table desired/accurate?

The following table is a list of recommended URLs and their purpose:
http://example.com/<myresource/compute		Define and configure machines
http://example.com/myresource/network		Network configuration
http://example.com/myresource/storage		Storage services (SANs, etc)
http://example.com/myresource/application	Application control

-- 
Michael Behrens

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg