[sldev] UUID variant/version bits?

[Lawson English]

Argent Stonecutter wrote:
> On 28-Nov-2007, at 16:41, Lawson English wrote:
>> Argent Stonecutter wrote:
>>> On 28-Nov-2007, at 13:59, Lawson English wrote:
>>>> The issue MAY be an issue once the meta-grid goes operational. 
>>>> You'll have to make sure everyone is using your version of UUIDs or 
>>>> asset-collisions might arise when moving from grid to grid.
>>>
>
>>> Unless someone has changed things recently, I believe that the 
>>> intent is for externally-visible assets to be presented as URIs, not 
>>> UUIDs.
>
>> Unless I misunderstand, the CAP for a given asset will be roughly of 
>> the form: server_URL:port/cap/asset/UUID.
>>
>> Where UUID is the current asset UUID
>
> (note, I'm using 'domain' in the generic sense of a set of systems and 
> resources with a single responsible control)
>
> The mapping from the internal UUID to an external URL will have to be 
> handled on a per-domain basis. Asset references between domains will 
> need to be handled by passing a URL out of the domain, and mapping 
> that URL if needed into a domain's internal ID model. There can not be 
> any assumptions about the meaning of the URL received from another 
> domain... it's got to be treated as an opaque token.
>
> If you're accessing http://asset_server:port/cap/asset/UUID and the 
> asset doesn't belong to that server, it's gotta return something like
>
> 302 Remote asset
>
> Location: http://otherguy:theirport/some/opaque/path/and/id
>
> And the asset server AND you can't make any assumptions about what 
> "/some/opaque/path/and/id" means.
>

But....

What if there is a collission between the UUIDs of two different 
domains? Unless you have the entire cap as the new asset ID, there will 
be collisions. I guess, at some point before the meta-grid goes live, 
asset-wise, LL will need to replace all LL-specific UUIDs with 
llDomain_URL caps. Guess that would actually work out fine, come to 
think of it, and should be trivial to implement.

Lawson