So, I’m totally on this page... Sort of. I used UUIDs exclusively with CloudScale. But...
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.
--Randy
On 4/16/09 6:12 AM, "Sam Johnston" <samj@samj.net> wrote:
I'm surprised I didn't get more abuse about using UUID4's but that's a no brainer when you understand the concurrency issues (and don't want to expose any secrets, particularly about the size of your operation).
--
Randy Bias, VP Technology Strategy, GoGrid
randyb@gogrid.com, (415) 939-8507 [mobile]
BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias