[Opensim-dev] Global identifiers
Melanie
melanie at t-data.com
Sun Aug 29 18:33:54 UTC 2010
I disagree strongly.
Assume object O has been created by user A on grid X.
He then rezzes a copy on grid Y and sets it for sale.
Grid X then goes down, either because it was just a temporary
standalone, or it went bankrupt, or got sued out of existence.
Someone buys O in Y and takes it to grid Z.
Now, what is grid Z going to display as creator name? It can't ask
grid X, since it's gone. Can't ask grid Y, as it would claim to be
nonauthoritative, even if it did have a cached value.
Result: attribution is lost.
This is why I believe the URL needs to contain enough information to
at least allow the display of the name of the creator as the creator
was known at that time and the grid of origin.
Melanie
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