[Opensim-dev] Global identifiers

diva at metaverseink.com diva at metaverseink.com
Sun Aug 29 16:55:19 UTC 2010


What Melanie is saying is that the URI stored in persistent storage is 
both the global reference (the part http://authority/user/uuid) and a 
simple cache (the part /Melanie+Milland).

This doesn't prevent grids from looking up the global reference part 
(i.e. update the cache) whenever they wish. And it does, indeed, reduce 
lookups significantly in the context of OpenSimulator.

I like it.

Mike Dickson wrote:
> Personally I think attaching additional semantics beyond just a unique
> ID that is associated with an Agent Service is a bad idea.  Beyond that
> a simple rest service definition that allows quick lookup and caching of
> id to user friendly names would solve the problem and in that case the
> service can make a decision on behalf of the user as to what information
> is valid to be shared (assuming a trust relationship exists betweem the
> grid services trying to access the information.
> 
> So IMO an agent id is simply a URL that identifies the scope (the agent
> service) and id of a user.  The service can then export whatever service
> interfaces are appropriate to allow access to additional data.
> 
> Mike
> 
> On Sun, 2010-08-29 at 16:13 +0000, Ideia Boa wrote:
>> We see the same problem than Zonja with our grid
>>
>> On 29-08-2010 5:27, Zonja Capalini wrote: 
>>> I see one small problem with this approach: UUIDs are immutable, 
>>> but it's conceivable that a world operator could allow certain form
>>> of
>>> updating of user names, while still retaining the same identity
>>> (I've had to manually edit user names in some cases in the worlds
>>> I administer, for a number of reasons).
>>>
>>>
>>> In this scenario, if an URI is resolved to a name that has changed
>>> this can potentially require a lot of updates in the database
>>> (e.g., if the foreign user has created many objects in the local
>>> world).
>>>
>>>
>>> OTOH, if the URI -> username association is stored in a different
>>> table,
>>> this table can also keep other, valuable, information, for example
>>> the
>>> date of the latest resolution, whether the world appears to be
>>> active atm, etc.
>>>
>>>
>>>   /Zonja
>>>
>>> On Sun, Aug 29, 2010 at 1:44 PM, Melanie <melanie at t-data.com> wrote:
>>>         We should.
>>>         
>>>         Also, we should use extra info in the URI. Reson:
>>>         
>>>         http://www.avination.net:8004/user/44626b40-13d6-4817-b61b-de5df7b5e7e8
>>>         
>>>         The above is totally meaningless. It can't be used to do
>>>         anything
>>>         with unless www.avination.net exists and points to a
>>>         gatekeeper.
>>>         
>>>         However,
>>>         
>>>         http://www.avination.net/user/44626b40-13d6-4817-b61b-de5df7b5e7e8/Melanie+Milland
>>>         
>>>         makes more sense here.
>>>         
>>>         The URI itself provides a "Display name" that the resolver
>>>         at that
>>>         URL can treat as extra path info and ignore, if it chooses.
>>>         
>>>         This would allow us to create a temporary memory cache
>>>         record of the
>>>         UUID -> name mapping that would let us display a prim
>>>         creator
>>>         without a lookup, which is a potentially frequent process.
>>>         
>>>         The sim can take the URL at face value and diassemble it,
>>>         using
>>>         44626b40-13d6-4817-b61b-de5df7b5e7e8 -> "Melanie
>>>         Milland at www.avination.net" for the cache and returning that
>>>         to the
>>>         viewer as the creator, all without a lookup.
>>>         
>>>         While this doesn't prevent verification of stale URI's from
>>>         failing,
>>>         it does allow to display a meaningful text if that happens.
>>>         
>>>         Melanie
>>>         
>>>         diva at metaverseink.com wrote:
>>>         > Looks like ppl are reading more into this discussion than
>>>         I intended.
>>>         >
>>>         > The hypergrid is up & running with all authentication and
>>>         security in
>>>         > place, and so are exchanges of content via HG and
>>>         archives. What's
>>>         > missing is *systematic* global identification of
>>>         resources. OpenSim
>>>         > already does that internally for resolving *certain*
>>>         identifiers on the
>>>         > Hypergrid, but nothing is stored persistently yet. That is
>>>         going to
>>>         > change soon, because 1) I want to make friends & IM work
>>>         across the HG
>>>         > (so, for example, your foreign friend needs to be
>>>         identified by a global
>>>         > ID); and 2) we really need to fix the b0rked "creator"
>>>         field in OARs/IARs.
>>>         >
>>>         > This means that we need to write URIs persistently, both
>>>         in certain
>>>         > fields of the DB (which is already prepared for what's
>>>         coming) and in
>>>         > the archives.
>>>         >
>>>         > So the issue here is really narrow. Assuming everyone
>>>         agrees that we
>>>         > should use URIs, should we add type information in the URI
>>>         or not? Any
>>>         > other thoughts on the *form* of these URIs?
>>>         >
>>>         >
>>>         > mysticaldemina at xrgrid.com wrote:
>>>         >> May be good to share what your use case is.  As universal
>>>         are you suggesting
>>>         >> an identifier that separate, potentially un-trusted
>>>         domains, would use to
>>>         >> identify the same person?
>>>         >>
>>>         >> Is so I don't think you can do that with two parties, you
>>>         need at least one
>>>         >> more party to validate that they are the same person,
>>>         like how we do with
>>>         >> SSL certificates, or with some kind of authentication,
>>>         like you send me an
>>>         >> email address which gets me to a profile, but I still
>>>         need to enter in a
>>>         >> password or something to get access to that profile.
>>>         >>
>>>         >> M.
>>>         >>
>>>         >> -----Original Message-----
>>>         >> From: opensim-dev-bounces at lists.berlios.de
>>>         >> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf
>>>         Of Ai Austin
>>>         >> Sent: Saturday, August 28, 2010 4:59 PM
>>>         >> To: opensim-dev at lists.berlios.de
>>>         >> Subject: Re: [Opensim-dev] Global identifiers
>>>         >>
>>>         >> diva wrote:
>>>         >>> I'm about to introduce global identifiers, so that I can
>>>         make friends
>>>         >>> and IM work on the hypergrid, and would like feedback on
>>>         the best form
>>>         >>> of these identifiers.
>>>         >>
>>>         >>> Here are some options:
>>>         >>> ... Thoughts?
>>>         >>
>>>         >>
>>>         >> A couple of thoughts and observations Diva...
>>>         >>
>>>         >> Could the taxonomy of "types" you use cause problems if
>>>         the chosen
>>>         >> 1-1 mapping for a UUID is not felt to work well i future.
>>>         >>
>>>         >> "user" is also perhaps a different notion to a specific
>>>         "avatar"
>>>         >>
>>>         >> It would be nice if any UUID in a URI you use can be
>>>         resolved (e.g.
>>>         >> to the avatar name) by any host that has the mapping
>>>         (like the
>>>         >> distributed nature of DNS works), so its not dependent on
>>>         the host
>>>         >> continuing to exist, or to be up at the time information
>>>         on the
>>>         >> avatar is sought.
>>>         >>
>>>         >> AS an example, we have shifted our data bases between
>>>         machines and
>>>         >> have done so 3 or 4 times since we started running
>>>         OpenSim, carrying
>>>         >> the UUIDs of avatars (and the UIIDs of regions we use)
>>>         forwards to
>>>         >> the new data bases.
>>>         >>
>>>         >> _______________________________________________
>>>         >> 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