On Fri, Apr 17, 2009 at 2:37 AM, Randy Bias <randyb@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