[Opensim-dev] Global identifiers

Tue Aug 31 01:35:28 UTC 2010

On 30/08/10 23:38, diva at 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?

God, you guys can certainly pump out the e-mails over the weekend :).

Diva, I've actually tackled this problem before from the perspective of preserving creator names in IAR transfers about 
a year ago.  This is summarized at a high level at

http://justincc.org/blog/2009/09/25/preserving-content-creator-credit-in-opensim-iar-transfers/

with some more in the wiki at http://opensimulator.org/wiki/OpenSim_Profile_Anchors.

This is what all the 'OpenSim Profile Anchor' (OSPA) stuff was about.  In that case, the proposed format was

ospa:n=Justin Clark-Casey,p=http://justincc.org/my-vw-profile

for property extensibility but a single URL (plus uuid) could well be better.  Along with Melanie, I thought it 
important to embed a simple user name, though more to handle the case where the lookup URL had gone away or no network 
was available.  Changed names could be substituted once the lookup URL could be reached.

The URL part of the OSPA was never done, though the name part is implemented in IARs today for creators and owners 
rather than a UUID.  On save, this OSPA is exported to the IAR.  On load, the name is resolved to an account on the 
receiving system.  That's very imperfect but still better than making no effort at all I think.

The part of OSPA that was completed is in the codebase at OpenSim.Framework.Communications:Osp.  OpenSim's inventory 
data plugin was wrapped in order to resolve stored external names to local UUIDs (in other words, temporary profiles 
were formed).  This code existed to support a permanent record of external IDs (the OSPAs) as well as maintaining 
compatibility with OpenSim's internal UUID system.  It was working but was disabled since I never got to sealing up all 
the holes in it (e.g. resolving ids for objects crossing in from other regions or as attachments, etc.)

In InventoryItemBase you can see some of the gymnastics I went through in order to store CreatorID as a string and yet 
not force OpenSim to constantly dereference it to a UUID.  It was extremely challenging to preserve backward compatibility.

I'm very glad you're taking a look at this, Diva, since I think that preserving creator attribution (via external IDs) 
is very important for a viable distributed virtual environment.  I did find a very large number of conceptual wrinkles 
when I was thinking about this last, and implementing things within the confines of the Second Life protocol was very 
difficult.  However, I'm sure that won't put you off ;).  If it's helpful, I can try and dig out from my notes and brain 
some more specifics about the issues that I encountered and considered.

Just for the record, http://authority/user/user_id/First+Last seems okay to me.

As a last point, using external UUIDs at the metadata level (e.g. in inventory items) is relatively simple.  However, 
substituting them for internal IDs down the stack of object assets and objects contained in other objects might be 
tricky, particularly with OpenSim's ghetto auto xml object format.  But I imagine that going this far down the 
implementation road might not be necessary for what you want to achieve right now.

To be honest, I think that keeping internal UUIDs and external unique identifiers is a mess.  Looking up profiles via 
the simulator is horrible anyway.  I think that it would ultimately be better to discard the internal IDs completely and 
just let the viewer look up the URLs directly.  However, I appreciate that this might not be an easy architectural shift 
to achieve.

>
> 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-bounces at lists.berlios.de [mailto:opensim-dev-
>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>> Sent: Monday, August 30, 2010 2:30 PM
>>> To: opensim-dev at 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, diva at 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 at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>

-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc