[occi-wg] name-based access to resources

[Sam Johnston]

Hi Adrian,

It looks like you were referring to the walkthrough which is now well out of
date. It will be updated at publication but in the mean time please refer to
the spec directly.

You'll see that URLs are now in fact opaque and leave structure to the
implementors/users (as is the case on the Internet today - we don't tell
people they have to put images in /images for example). We still have UUIDs
so as resources can be tracked as they move around within/between clouds (in
the same way that VMware virtualisation clients complain when you move VMs
and ask if you want to keep the old UUID or generate a new one) but they are
attributes.

This allows people to create sensible URL structures like
http://cloud.amazon.com/images/ami-123456 which the clients learn from the
protocol itself (in line with RESTful principles).

Hope that helps,

Sam

On Wed, Oct 21, 2009 at 2:26 AM, Adrian Cole <adrian at jclouds.org> wrote:

> Hello, WG.
>
> In re-reading the OCCI spec, something became clear to me I frankly
> hadn't noticed before:  All operations require system-generated ids.
> POST creates an object and returns a url containing its UUID.  All
> other operations require this UUID.  UUIDs are important, and there
> will be systems that should use this for efficiency's sake.  However,
> moderate use would pretty much require users to store a mapping
> between what they call a resource and its UUID.  This mapping would
> end up as another table or cache that clients would need to maintain.
>
> The alternate path is a name-based interface to the system that allows
> access to resources based on ids the client decides.  A good example
> of this is atmos online, where they have 2 interfaces: /objects and
> /namespace but offer the same methods on each.  For convenience,
> namespace methods return the UUID in a response header, so one can
> later switch.  Regardless, clients do not need to parse metadata or
> listings to access their resources as they are available by their
> natural names.
>
> Is this something we can consider supporting in OCCI?
>
> Regards,
> -Adrian
> jclouds
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091021/ab599654/attachment.html