I think Jorge's "bookmark" links refer to an Atom permalink. Jorge, is that correct?
-jay On Fri, Jun 3, 2011 at 11:34 AM, Thorsten von Eicken <t...@rightscale.com> wrote: > 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? > Thorsten > > On 6/3/2011 5:39 AM, Jorge Williams wrote: > > 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. > -jOrGe W. > On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote: > > 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. > > 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: > {"server"=> > {"name"=>"kd_test_3", > "flavorRef"=>"http://5.5.2.2:8774/v1.1/flavors/3", > "addresses"=> > {"public"=>[], "private"=>[{"version"=>4, "addr"=>"5.5.2.5"}]}, > "metadata"=>{"v2"=>"d2", "4"=>"14", "5"=>"17"}, > "imageRef"=>"http://5.5.2.2:8774/v1.1/images/1", > "id"=>26, > "hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5", > "links"=> > [{"href"=>"http://5.5.2.2:8774/v1.1/servers/26", "rel"=>"self"}, > {"href"=>"http://5.5.2.2:8774/v1.1/servers/26", > "rel"=>"bookmark", > "type"=>"application/json" > }, > {"href"=>"http://5.5.2.2:8774/v1.1/servers/26", > "rel"=>"bookmark", > "type"=>"application/xml" > } > ], > "status"=>"ACTIVE" > } > } > 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. > > Our recommendation: > - option 1: use canonical hrefs that can be used as unique IDs, which means > without host/port and without version number > - 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 > > 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. > > Thanks much! > Thorsten - CTO RightScale > > > On 6/2/2011 12:40 PM, Jay Pipes wrote: > > On Thu, Jun 2, 2011 at 1:18 PM, George Reese <george.re...@enstratus.com> > wrote: > > I hate UUIDs with a passion. > > * They are text fields, which means slower database indexes > > 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. > > * They are completely user-unfriendly. The whole "copy and paste" argument > borders on silliness > > 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. > > * And uniqueness across regions for "share nothing" can be managed with a > variety of alternative options without resorting to the ugliness that is > UUIDs > > 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: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > 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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp