This looks to me to be an attempt to provide local caching of relevant information for reducing lookup requirements and seems a usable approach as long as the extra data is known to be non-authoritative. It does bring a implementation-specific form into something that has potential to becoming a standard of sorts and that may be a concern. It does not appear to address the problem of fly-by-night service providers or those who may try to profit excessively from a position of providing an authority. Personally I don't like the idea of having a paid subscription service having any control over my ability to surf the hypergrid, and as such I''d prefer to see the UUID portion be the authoritative lookup key and the lookup domain portion be considered a suggestion at best. UUIDs by design have sufficient variability where collisions are highly unlikely so I don't see collisions as being an issue even if they are independently generated by independent providers.<br>
<br><div class="gmail_quote">On Sun, Aug 29, 2010 at 4:44 AM, 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>