[Opensim-dev] Global identifiers

Melanie melanie at t-data.com
Tue Aug 31 20:05:42 UTC 2010 

See my prior messages. That format is inherently un-cacheable. I
believe the mandatory info needs to be part of a URL that can be
fetched with GET and cached, e.g. is RESTful.

Melanie

Dahlia Trimble wrote:
> I've tried to use extra information in URLs before by slash-delimiting them
> and all seemed to work well until I ran into situations such as missing data
> for one of the terms and some URL parsers did not accept the double slash
> which resulted from the missing field. Another problem exists when extending
> the definition at a later date, then all parsers that have to deal with the
> URL have to be modified. After banging my head over these kind if issues I
> went back and redesigned it to use the &name=value format and I''ve never
> regretted it since. Parsing it is quite simple in C# with String.Split()
> 
> Given the open source nature of OpenSimulator, I would think diverging
> definitions would be unavoidable and would likely hinder interoperability
> unless some means for allowing flexibility was designed in from the start,
> and I think name-value pairs are a usable means of providing that
> flexibility.
> 
> 
> On Tue, Aug 31, 2010 at 7:53 AM, <diva at metaverseink.com> wrote:
> 
>> Hurliman, John wrote:
>>
>>> It sounds like the decision has been made (or was already made before this
>>> discussion started), so on to the next step. Can you (Melanie or Diva) do
>>> these two things?
>>>
>>
>> As I said, the issue was *really* narrow :) Even though the interfaces
>> already account for this, I got scared when I faced the situation of
>> actually creating persistent references to external data. (or, in the case
>> of Simian, creating persistent data structures representing external data,
>> which is similar)
>>
>>
>>  1) Define exactly how the URL is supposed to be parsed. ABNF notation
>>> would be preferred, or something equivalent that makes it clear what
>>> identifiers are valid or invalid. Or perhaps define any URL as valid like
>>> diva suggested, but only parse display names out of specifically crafted
>>> URLs. With the suggested format of
>>> http://authority/user/user_id/First+Last it seems like you would either
>>> assume any URL that includes a space in the last section of the path is
>>> parsed as a first+last name tuple. (I'm assuming you remove any attached
>>> query string before parsing the name.) Or will it look for "user_id" as the
>>> second to last segment of the path followed by a path segment containing a
>>> space? Obviously it can't expect /user/user_id/First+Last to be anchored at
>>> the root of the domain since it won't be possible to generate those URLs on
>>> some setups.
>>>
>>
>> Yes, and that's the crux of the narrow issue in discussion. So let's finish
>> those little details on the IRC, maybe.
>>
>>
>>  2) Standardize the handling of external identities in OpenSim. Go through
>>> and clean out the approaches that are no longer being used, such as
>>> OpenSim.Framework.Communications.Osp. I can help with this part as I'm
>>> always a fan of removing dead code.
>>>
>>
>> That's the only broad consequence of this issue, and one that I also feel
>> it's very important. I know these global names have been used before -- or
>> maybe never used, but the code is there -- and, even though I didn't
>> remember the syntax, I remembered that it looked nothing like an URI.
>> Thanks, Justin, for explaining. If everyone is ok with the URI syntax, then
>> let's make it consistent across the board.
>>
>>
>>
>>> John
>>>
>>>  -----Original Message-----
>>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>>> bounces at lists.berlios.de] On Behalf Of diva at metaverseink.com
>>>> Sent: Monday, August 30, 2010 3:39 PM
>>>> To: opensim-dev at lists.berlios.de
>>>> Subject: Re: [Opensim-dev] Global identifiers
>>>>
>>>> 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-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
>>>>
>>> _______________________________________________
>>> 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

More information about the Opensim-dev mailing list