I would lobby for the "user id" being a UUID rather than a string simply because of the uniqueness of the UUID.<br><br>For example I use "Karen Palen" as userid on more than a dozen grids and several email addresses (Karen has even been issued a Credit Card!!!). Need I add that "Karen Palen" is a pseudonym, :-)<br>
<br>I am very concerned about the potential for resolution problems, especially where the same id was previously used in several places which are now part of some unified naming convention.<br><br>There seem to be four cases:<br>
<br>1) lookup <a href="http://authority.">http://authority.</a>.. - get a valid update<br>2) <a href="http://authority.">http://authority.</a>.. does not exist (temporary or permanent) - cache not updated, use the latest information available after checking the URL mapping (below)<br>
3) <a href="http://authority.">http://authority.</a>.. changed to another URL - update the URL and save the URL mapping for other references to "<a href="http://authority">http://authority</a>"<br>4) <a href="http://authority.">http://authority.</a>.. resolves to more than one "authority". Possibly due to malfeasance (spoofing), more likely due to several changes in "<a href="http://authotity">http://authotity</a>" over time and outdated information. - resolve this ambiguity by reference to other users of "<a href="http://authority">http://authority</a>". <br>
<br>In the most pathological case of (4) several "authorities" will respond as valid, requiring some sort of probabilistic resolution - "most likely" the most recent "authority" provided that 90+% (or whatever) of UUIDs referring to "authority" now resolve to this authority. This implies several unresolvable possibilities and a high probability of picking the wrong one!<br>
<br>Case 4 should be very rare if a UUID is used, but quite common if a common name (like "Karen Palen") is used!<br><br>In real life me exact name "googles" to 25 people in the Phoenix area, at one time I had a namesake working in the same building as me! A literature search is even worse, my "tribe" seem to be prolific authors with many papers in biotech, medicine, computer science, electrical engineering, and several other fields. One of them is a member of the US Congress!<br>
<br>Much as we like to think otherwise, our names are NOT unique!<br><br>Karen<br><br><div class="gmail_quote">On Mon, Aug 30, 2010 at 3:38 PM, <span dir="ltr"><<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">OK, so here's the form of the URI that will start showing up in the [non-Simian] DBs soon, specifically in the GridUser table:<br>
<a href="http://authority/user/user_id/First+Last" target="_blank">http://authority/user/user_id/First+Last</a><br>
<br>
Yes?<br>
<br>
I suspect that SimianGrid will take things like<br>
LoggedIn(string userID) and<br>
StoreGridUserInfo(GridUserInfo info)<br>
<br>
and create user accounts for these if they don't exist, because I think SimanGrid collapses the 2 concepts. Just keep in mind that you'll soon be receiving URLs of the form above as arguments.<br>
<br>
I agree with Melanie that not adding the display name is a missed opportunity for caching, but I'm willing to write up code that accounts for it being optional for all the grid operators who would rather have the extra lookups coming their way.<div>
<div></div><div class="h5"><br>
<br>
Hurliman, John wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If we are still on the same page, there should never be a case where something could be either a local identifier (UUID) or a global identifier (URL). The context is always clear, where cross-grid communication and exported content uses only global identifiers and all intra-grid communication uses only local identifiers. If a sim wants to resolve the creator of a prim it uses a single path, the UUID->Profile (aka display name) API call which takes advantage of all the caching and optimizations we've built into OpenSim. There is no ambiguity there or potential for the code to take a slower or less tested path. The discussion is about communication outside of the local grid context, when you are exporting content or moving people or content between grids. In every use case there I think it makes sense to always use global identifiers, or at least a clear path to build a global identifier.<br>
<br>
John<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
-----Original Message-----<br>
From: <a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-" target="_blank">opensim-dev-</a><br>
<a href="mailto:bounces@lists.berlios.de" target="_blank">bounces@lists.berlios.de</a>] On Behalf Of Melanie<br>
Sent: Monday, August 30, 2010 2:30 PM<br>
To: <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
Subject: Re: [Opensim-dev] Global identifiers<br>
<br>
I think we already have a perfectly good field, which is a UUID for<br>
local users and a URL for remote ones.<br>
<br>
Melanie<br>
<br>
Serendipity Seraph wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 8/30/10 2:09 PM, <a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hurliman, John wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
My interpretation (please correct me if I'm wrong) is that there is<br>
rough consensus on the overall strategy, but an open question of<br>
</blockquote></blockquote></blockquote>
how<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
to encode global identities when cross-grid communication (or<br>
out-of-grid archiving) happens.<br>
</blockquote>
That's what's going on.<br>
Up to now, all global identifiers (that already exist) have been<br>
volatile; nothing has persisted. As I found myself writing code that<br>
would inject global identifiers into a DB table, I thought we should<br>
all talk about the form of such identifiers.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
There is probably also a hidden question of how to mark a local<br>
account as linked to a foreign identity, which may solve the<br>
friending issue. If I am friends with your avatar and we are both<br>
</blockquote></blockquote></blockquote>
on<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
grid B but your avatar actually originated from grid A, that link<br>
</blockquote></blockquote></blockquote>
in<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
the profile is what can tip off the presence service to try a<br>
</blockquote></blockquote></blockquote>
remote<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
presence check (assuming the user is not online in the local grid).<br>
My only interest in these low level questions like how the global<br>
identifiers and profile links look is what the final decision is so<br>
</blockquote></blockquote></blockquote>
I<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
can implement it in the OpenSim SimianGrid connectors.<br>
</blockquote>
Well, we distinguish "user accounts" from "grid users" -- these are<br>
</blockquote></blockquote>
2<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
different interfaces, although implementers may decide to collapse<br>
them. But they are different concepts. User accounts are the<br>
locally-registered users; in some cases, like for example, the UCI<br>
grid, there's only some people who can get accounts there, namely<br>
people associated with the university. Grid users are users that are<br>
referenced by things that happen in the grid. So we already have an<br>
interface for that, although now I'm thinking that perhaps we need<br>
</blockquote></blockquote>
to<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
separate its UserID field into 2 things: a local UUID and a<br>
</blockquote></blockquote>
reference<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
to the external name. And I guess that's my main issue at this<br>
</blockquote></blockquote>
point.<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It seems more reasonable in a distributed system to say that an X is<br>
</blockquote>
an<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
X - a User is a User, whether they originally were instantiated on a<br>
local or a remote system. So I would go for collapsing the two as<br>
</blockquote>
much<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
as possible as a matter of policy. Otherwise freedom to move between<br>
nodes in the system is more limited and there is more special case<br>
</blockquote>
logic<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
to deal with. But that is speaking from a general distributed<br>
computing perspective. There may be many Opensim details that make<br>
</blockquote>
that<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
seemingly ideal position in practice rather naive.<br>
<br>
- s<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>
</blockquote>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>
</blockquote>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>
</blockquote>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>