[Opensim-dev] Global identifiers
diva at metaverseink.com
diva at metaverseink.com
Sun Aug 29 16:29:47 UTC 2010
I already said this, but let me stress it again.
OpenSim does not use global identifiers for *local* resources (read
local users). So if you change the name of your users while keeping
their UUIDs, the names associated with the objects in *your* world will
be always the latest ones. You don't need a table lookup.
Global identifiers are used *only* in references to external resources
that have been imported in some way.
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
>> <mailto: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 <http://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 <mailto: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 <mailto: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 <mailto: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>
>> >> [mailto: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
>> <mailto: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 <mailto:Opensim-dev at lists.berlios.de>
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >>
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >>
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto: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