It seems to me that is the true "name" is the UUID then the problem goes away - th eUUID can point to any text string (or other display information for that matter).<br><br>The problem simply disappears!<br><br>Karen<br>
<br><div class="gmail_quote">On Mon, Aug 30, 2010 at 2:39 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;">
I know. But what about when we get to 1.1 and we want to start bridging the social network with other non-VW social networks? Their external references look different than the ones we are talking about here, and we will need a local UUID for those; where do we stick it?<br>
<br>
...Should we cross that bridge later?<div><div></div><div class="h5"><br>
<br>
Melanie wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 how<br>
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 on<br>
grid B but your avatar actually originated from grid A, that link in<br>
the profile is what can tip off the presence service to try a remote<br>
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 I<br>
can implement it in the OpenSim SimianGrid connectors.<br>
</blockquote>
Well, we distinguish "user accounts" from "grid users" -- these are 2<br>
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 to<br>
separate its UserID field into 2 things: a local UUID and a reference<br>
to the external name. And I guess that's my main issue at this point.<br>
<br>
</blockquote>
It seems more reasonable in a distributed system to say that an X is an<br>
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 much<br>
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 logic<br>
to deal with. But that is speaking from a general distributed<br>
computing perspective. There may be many Opensim details that make that<br>
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>
<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>