[occi-wg] Syntax of OCCI API

[Sam Johnston]

On Fri, Apr 17, 2009 at 2:37 AM, Randy Bias <randyb at gogrid.com> wrote:

> The only downside of UUIDs is they aren’t people-friendly.  For example,
> trying to remember or type in and verify a UUID by eye is very error-prone.
>  So if you were a sysadmin writing some bourne shell scripts to help with
> automation or just using some command line tools, it’s going to be painful.
>  You can imagine:
>
>     clitool –delete disk –disk-id <some-really-long-uuid-string-is-here>
> -server <another-really-long-uuid-string-is-here> ...
> <yet-another-really-long-uuid-string>
>
> Another example would be listings of any kind.  If strewn with UUIDs they
> are going to be super hard for people to parse visually.
>
> I’d prefer that folks use UUIDs internally, that we have the spec say
> string(256) for most identifiers, and that providers can choose to use UUIDs
> or something more friendly (e.g. the canonical AMI id: ami-abcd1234) as
> appropriate.


This is something I had considered too but it runs counter to the "great
global grid" use case. I don't think moving away from UUIDs for the core is
sensible (if you give people enough rope they *will* hang themselves, as
they have proven time and time again)...

But, if the category/tagging functionality does not satisfy this use case
then my suggestion would be to assign optional aliases to frequently used
resources (e.g. Amazon's "small", "medium" and "large" templates). This
would add implementation headaches (e.g. having to implement a central
registry which would need to be available at creation time) but write
operations would be few and far between (at least compared to normal
operations).

So for tags/categories you have:

http://example.com/-/linux/web (to retrieve all linux web servers you have
access to)

And for aliases you might have:

http://example.com/myserver (rather than a long, ugly UUID)

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090417/9ac2a0ab/attachment.html