It's a UUID.
Display names are *never* used as identifiers in OpenSim. They're just
human-friendly tags that usually take the value of the user account
name, but that can change at any time if you happen to land in a
simulator with a sense of humor :)
And in the HG, UUIDs themselves are also 'unique' in the sense that the
Gatekeepers don't let agents come in, that happen to claim a UUID of a
local user.
Karen Palen wrote:
I would lobby for the "user id" being a UUID rather than a string simply
because of the uniqueness of the UUID.
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, :-)
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.
There seem to be four cases:
1) lookup http://authority... - get a valid update
2) http://authority... does not exist (temporary or permanent) - cache
not updated, use the latest information available after checking the URL
mapping (below)
3) http://authority... changed to another URL - update the URL and save
the URL mapping for other references to "http://authority";
4) http://authority... resolves to more than one "authority". Possibly
due to malfeasance (spoofing), more likely due to several changes in
"http://authotity"; over time and outdated information. - resolve this
ambiguity by reference to other users of "http://authority";.
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!
Case 4 should be very rare if a UUID is used, but quite common if a
common name (like "Karen Palen") is used!
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!
Much as we like to think otherwise, our names are NOT unique!
Karen
On Mon, Aug 30, 2010 at 3:38 PM, <d...@metaverseink.com
<mailto:d...@metaverseink.com>> wrote:
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:
http://authority/user/user_id/First+Last
Yes?
I suspect that SimianGrid will take things like
LoggedIn(string userID) and
StoreGridUserInfo(GridUserInfo info)
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.
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.
Hurliman, John wrote:
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.
John
-----Original Message-----
From: opensim-dev-boun...@lists.berlios.de
<mailto:opensim-dev-boun...@lists.berlios.de>
[mailto:opensim-dev- <mailto:opensim-dev->
boun...@lists.berlios.de <mailto:boun...@lists.berlios.de>]
On Behalf Of Melanie
Sent: Monday, August 30, 2010 2:30 PM
To: opensim-dev@lists.berlios.de
<mailto:opensim-dev@lists.berlios.de>
Subject: Re: [Opensim-dev] Global identifiers
I think we already have a perfectly good field, which is a
UUID for
local users and a URL for remote ones.
Melanie
Serendipity Seraph wrote:
On 8/30/10 2:09 PM, d...@metaverseink.com
<mailto:d...@metaverseink.com> wrote:
Hurliman, John wrote:
My interpretation (please correct me if I'm
wrong) is that there is
rough consensus on the overall strategy, but an
open question of
how
to encode global identities when cross-grid
communication (or
out-of-grid archiving) happens.
That's what's going on.
Up to now, all global identifiers (that already
exist) have been
volatile; nothing has persisted. As I found myself
writing code that
would inject global identifiers into a DB table, I
thought we should
all talk about the form of such identifiers.
There is probably also a hidden question of how
to mark a local
account as linked to a foreign identity, which
may solve the
friending issue. If I am friends with your
avatar and we are both
on
grid B but your avatar actually originated from
grid A, that link
in
the profile is what can tip off the presence
service to try a
remote
presence check (assuming the user is not online
in the local grid).
My only interest in these low level questions
like how the global
identifiers and profile links look is what the
final decision is so
I
can implement it in the OpenSim SimianGrid
connectors.
Well, we distinguish "user accounts" from "grid
users" -- these are
2
different interfaces, although implementers may
decide to collapse
them. But they are different concepts. User accounts
are the
locally-registered users; in some cases, like for
example, the UCI
grid, there's only some people who can get accounts
there, namely
people associated with the university. Grid users
are users that are
referenced by things that happen in the grid. So we
already have an
interface for that, although now I'm thinking that
perhaps we need
to
separate its UserID field into 2 things: a local
UUID and a
reference
to the external name. And I guess that's my main
issue at this
point.
It seems more reasonable in a distributed system to say
that an X is
an
X - a User is a User, whether they originally were
instantiated on a
local or a remote system. So I would go for collapsing
the two as
much
as possible as a matter of policy. Otherwise freedom to
move between
nodes in the system is more limited and there is more
special case
logic
to deal with. But that is speaking from a general
distributed
computing perspective. There may be many Opensim
details that make
that
seemingly ideal position in practice rather naive.
- s
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
<mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
<mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
