<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Really? The way I understand it, when I retrieve resource X I will
get a bookmark link for X. But when I retrieve resource Y that
happens to have a reference to X this references will not include
the bookmark link for X, it will just include X's URL. I'd then have
to retrieve that URL, which would get me that resource's bookmark
link and then realize that this is actually X which I already have.
Or perhaps I'm not understanding the docs correctly?<br>
Thorsten<br>
<br>
On 6/3/2011 5:39 AM, Jorge Williams wrote:
<blockquote
cite="mid:14719_1307104783_p53CdcJ5015834_6901E77C-6AE7-4FC6-9536-DD43B698D1B7@rackspace.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
<div>The whole idea behind the "bookmark" links is to give you the
functionality that you want -- that is a URL without a version
number in it. Looks like the implementation hasn't yet added
support for that, but it will.</div>
<div><br>
</div>
<div>-jOrGe W. </div>
<br>
<div>
<div>On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">We neither hate nor love
UUIDs, but we like them when they provide value and we also
accept alternatives. What we do hate is ambiguity and in
certain cases UUIDs help.<br>
<br>
Look at the hrefs returned in this sample resource and
picture what you'd store in your database as unique
identifier to refer to each one:<br>
<div>
<div>{"server"=></div>
<div> {"name"=>"kd_test_3",</div>
<div> "flavorRef"=>"<a moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/flavors/3">http://5.5.2.2:8774/v1.1/flavors/3</a>",</div>
<div> "addresses"=></div>
<div> {"public"=>[],
"private"=>[{"version"=>4,
"addr"=>"5.5.2.5"}]},</div>
<div> "metadata"=>{"v2"=>"d2", "4"=>"14",
"5"=>"17"},</div>
<div> "imageRef"=>"<a moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/images/1">http://</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/flavors/3">5.5.2.2</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/images/1">:8774/v1.1/images/1</a>",</div>
<div> "id"=>26,</div>
<div>
"hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5",</div>
<div> "links"=></div>
<div> [{"href"=>"<a moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">http://</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/flavors/3">5.5.2.2</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">:8774/v1.1/servers/26</a>",
"rel"=>"self"},</div>
<div> {"href"=>"<a moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">http://</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/flavors/3">5.5.2.2</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">:8774/v1.1/servers/26</a>",</div>
<div> "rel"=>"bookmark",</div>
<div> "type"=>"application/json"</div>
<div> },</div>
<div> {"href"=>"<a moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">http://</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/flavors/3">5.5.2.2</a><a
moz-do-not-send="true"
href="http://50.56.22.22:8774/v1.1/servers/26">:8774/v1.1/servers/26</a>",</div>
<div> "rel"=>"bookmark",</div>
<div> "type"=>"application/xml"</div>
<div> }</div>
<div> ],</div>
<div> "status"=>"ACTIVE"</div>
<div> }</div>
<div>}</div>
</div>
<br>
Are the hostnames significant? Are the port numbers
significant? Are the version IDs significant? Is the next
URI component significant? Is the integer ID significant?
Mhhh, maybe it's obvious to the OpenStack implementers, but
it leaves quite some room for error for all the users out
there. We end up having to write a little algorithm that
throws away the hostname and port, then throws away the
version number if there is one -- it really should NOT be
part of the URL! -- then looks at the next path component to
decide whether its the resource type and whether the path
component after that is the resource id, or whether there is
further nesting of path components. Then we can assemble a
unique ID and see whether we know about that resource or
need to fetch it. It would be really nice to have a UUID
attribute that eliminates this guesswork and we like UUIDs
that start with a type-specific prefix, such as inst-12345
or img-12345.<br>
<br>
Our recommendation:<br>
- option 1: use canonical hrefs that can be used as unique
IDs, which means without host/port and without version
number<br>
- option 2: use a unique ID with a type prefix and include
that as attribute in hrefs, we like small IDs, but we don't
care that much<br>
<br>
WRT UUIDs, we try to use integer IDs when we can easily
generate them centrally, but switch to UUIDs when we need to
distribute the ID generation and we keep them as short as
practical.<br>
<br>
Thanks much!<br>
Thorsten - CTO RightScale<br>
<br>
<br>
On 6/2/2011 12:40 PM, Jay Pipes wrote:
<blockquote
cite="mid:BANLkTikb_yU_O-9f4MN6x4pEiATys4J3sw@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Jun 2, 2011 at 1:18 PM, George Reese <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.reese@enstratus.com"><george.reese@enstratus.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I hate UUIDs with a passion.
* They are text fields, which means slower database indexes
</pre>
</blockquote>
<pre wrap="">Text fields are stored on disk/in memory as bytes the same as any
integer. It's that the number of bytes needed to store it is greater,
resulting in larger indexes and more bytes to store the keys. But, as
Jorge mentioned, some databases have native support for large-integer
types like UUIDs.
</pre>
<blockquote type="cite">
<pre wrap="">* They are completely user-unfriendly. The whole "copy and paste" argument borders on silliness
</pre>
</blockquote>
<pre wrap="">Yes, it's not easy to remember UUIDs. That's why virtually every
resource has some other way of identifying themselves. Typically, this
is a name attribute, though not all resources enforce uniqueness on
the name attribute, thus the need for a unique identifier.
I don't see people manually looking up resources based on UUIDs. I see
*machines* manually looking up resources based on UUIDs, and humans
looking up resources by, say, name, or (name, tenant_id) or (name,
user_id), etc.
</pre>
<blockquote type="cite">
<pre wrap="">* And uniqueness across regions for "share nothing" can be managed with a variety of alternative options without resorting to the ugliness that is UUIDs
</pre>
</blockquote>
<pre wrap="">Like URIs? I don't know of any other options that would work. Please
let us know what you think about in this respect.
-jay
_______________________________________________
Mailing list: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
Post to : <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
More help : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
<pre>Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at <a class="moz-txt-link-abbreviated" href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and delete the original message.
Your cooperation is appreciated.
</pre>
</blockquote>
</body>
</html>