[Opensim-dev] Global identifiers
diva at metaverseink.com
diva at metaverseink.com
Sun Aug 29 17:06:54 UTC 2010
More generally,
protocol://authority/resource_type/resource_id[/cacheable_data]
The more I look at this, the more I like it.
diva at metaverseink.com wrote:
> 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
>>
> _______________________________________________
> 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