I see one small problem with this approach: UUIDs are immutable,<div>but it's conceivable that a world operator could allow certain form of</div><div>updating of user names, while still retaining the same identity</div>
<div>(I've had to manually edit user names in some cases in the worlds</div><div>I administer, for a number of reasons).</div><div><br></div><div>In this scenario, if an URI is resolved to a name that has changed</div>
<div>this can potentially require a lot of updates in the database</div><div>(e.g., if the foreign user has created many objects in the local world).</div><div><br></div><div>OTOH, if the URI -> username association is stored in a different table,</div>
<div>this table can also keep other, valuable, information, for example the</div><div>date of the latest resolution, whether the world appears to be active atm, etc.</div><div><br></div><div>  /Zonja</div><div><div><br><div class="gmail_quote">
On Sun, Aug 29, 2010 at 1:44 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We should.<br>
<br>
Also, we should use extra info in the URI. Reson:<br>
<br>
<a href="http://www.avination.net:8004/user/44626b40-13d6-4817-b61b-de5df7b5e7e8" target="_blank">http://www.avination.net:8004/user/44626b40-13d6-4817-b61b-de5df7b5e7e8</a><br>
<br>
The above is totally meaningless. It can't be used to do anything<br>
with unless <a href="http://www.avination.net" target="_blank">www.avination.net</a> exists and points to a gatekeeper.<br>
<br>
However,<br>
<br>
<a href="http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland" target="_blank">http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland</a><br>
<br>
makes more sense here.<br>
<br>
The URI itself provides a "Display name" that the resolver at that<br>
URL can treat as extra path info and ignore, if it chooses.<br>
<br>
This would allow us to create a temporary memory cache record of the<br>
UUID -> name mapping that would let us display a prim creator<br>
without a lookup, which is a potentially frequent process.<br>
<br>
The sim can take the URL at face value and diassemble it, using<br>
44626b40-13d6-4817-b61b-de5df7b5e7e8 -> "Melanie<br>
<a href="mailto:Milland@www.avination.net">Milland@www.avination.net</a>" for the cache and returning that to the<br>
viewer as the creator, all without a lookup.<br>
<br>
While this doesn't prevent verification of stale URI's from failing,<br>
it does allow to display a meaningful text if that happens.<br>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="h5"><br>
<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a> wrote:<br>
> Looks like ppl are reading more into this discussion than I intended.<br>
><br>
> The hypergrid is up & running with all authentication and security in<br>
> place, and so are exchanges of content via HG and archives. What's<br>
> missing is *systematic* global identification of resources. OpenSim<br>
> already does that internally for resolving *certain* identifiers on the<br>
> Hypergrid, but nothing is stored persistently yet. That is going to<br>
> change soon, because 1) I want to make friends & IM work across the HG<br>
> (so, for example, your foreign friend needs to be identified by a global<br>
> ID); and 2) we really need to fix the b0rked "creator" field in OARs/IARs.<br>
><br>
> This means that we need to write URIs persistently, both in certain<br>
> fields of the DB (which is already prepared for what's coming) and in<br>
> the archives.<br>
><br>
> So the issue here is really narrow. Assuming everyone agrees that we<br>
> should use URIs, should we add type information in the URI or not? Any<br>
> other thoughts on the *form* of these URIs?<br>
><br>
><br>
> <a href="mailto:mysticaldemina@xrgrid.com">mysticaldemina@xrgrid.com</a> wrote:<br>
>> May be good to share what your use case is.  As universal are you suggesting<br>
>> an identifier that separate, potentially un-trusted domains, would use to<br>
>> identify the same person?<br>
>><br>
>> Is so I don't think you can do that with two parties, you need at least one<br>
>> more party to validate that they are the same person, like how we do with<br>
>> SSL certificates, or with some kind of authentication, like you send me an<br>
>> email address which gets me to a profile, but I still need to enter in a<br>
>> password or something to get access to that profile.<br>
>><br>
>> M.<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a><br>
>> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Ai Austin<br>
>> Sent: Saturday, August 28, 2010 4:59 PM<br>
>> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>> Subject: Re: [Opensim-dev] Global identifiers<br>
>><br>
>> diva wrote:<br>
>>> I'm about to introduce global identifiers, so that I can make friends<br>
>>> and IM work on the hypergrid, and would like feedback on the best form<br>
>>> of these identifiers.<br>
>><br>
>>> Here are some options:<br>
>>> ... Thoughts?<br>
>><br>
>><br>
>> A couple of thoughts and observations Diva...<br>
>><br>
>> Could the taxonomy of "types" you use cause problems if the chosen<br>
>> 1-1 mapping for a UUID is not felt to work well i future.<br>
>><br>
>> "user" is also perhaps a different notion to a specific "avatar"<br>
>><br>
>> It would be nice if any UUID in a URI you use can be resolved (e.g.<br>
>> to the avatar name) by any host that has the mapping (like the<br>
>> distributed nature of DNS works), so its not dependent on the host<br>
>> continuing to exist, or to be up at the time information on the<br>
>> avatar is sought.<br>
>><br>
>> AS an example, we have shifted our data bases between machines and<br>
>> have done so 3 or 4 times since we started running OpenSim, carrying<br>
>> the UUIDs of avatars (and the UIIDs of regions we use) forwards to<br>
>> the new data bases.<br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div></div>