[Opensim-dev] Global identifiers
Cristina Videira Lopes
lopes at ics.uci.edu
Wed Sep 1 00:58:25 UTC 2010
Sorry, fractured thoughts today...
These literal URLs are only used for profiles. The authority and the
user_id in these URLs are the important pieces of information, and
they are used for many other things, such as sending IM, sending
inventory, etc.
It would be really nice to have consistent REST-style handlers for
doing these things... These handlers don't exist yet...
On Aug 31, 2010, at 5:37 PM, Cristina Videira Lopes wrote:
> Something to keep in mind:
> For the time being, we're talking about URLs that would likely GET
> people's profiles -- that'd be the only time at which these global
> identifiers would be invoked.
>
> Again, HG authentication has nothing to do with this, it doesn't
> even use these particular references.
>
> On Aug 31, 2010, at 4:09 PM, Melanie wrote:
>
>> According to the tenets of REST, if you do need to retrieve data
>> that is constant, you use GET and caches may cache it.
>>
>> If you want to initiate something, like a chat, you would use POST.
>>
>> Caches are not eternal. So retrieval of profile info may be slightly
>> out of date (depending on cache ttl).
>>
>> POSTed chat requests, etc, won't be cached, as POST replies are
>> uncacheable.
>>
>> Melanie
>>
>> Dahlia Trimble wrote:
>>> OK, so if all the information needed is in the URL and the URL is
>>> cache
>>> friendly, what if whatever information the URL is supposed to
>>> reference
>>> changes upstream? How is it ever going to be retrieved? You've
>>> already
>>> designed a cache into the system with the format of the URL, at
>>> what point
>>> were you even considering making the request?
>>>
>>> On Tue, Aug 31, 2010 at 3:13 PM, Melanie <melanie at t-data.com> wrote:
>>>
>>>> I'm not relying on one. I'm imagining a world where VW traffic is
>>>> the main part of internet traffic, having displaced the flatweb.
>>>> For
>>>> ISP caching, it's important that most protocols are designed to be
>>>> RESTful. I don't plan on caching, but i don't want to create a
>>>> protocol that is inherently uncacheable. Be nice to the net.
>>>>
>>>> Melanie
>>>>
>>>> Dahlia Trimble wrote:
>>>>> if you're relying on an external cache, why do you need to store
>>>>> the same
>>>>> information in the url?
>>>>>
>>>>> On Tue, Aug 31, 2010 at 1:05 PM, Melanie <melanie at t-data.com>
>>>>> wrote:
>>>>>
>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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