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 <[email protected]> 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 > > [email protected]" 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 > > > > [email protected] 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? > > > > > > > > > [email protected] 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: [email protected] > > >> [mailto:[email protected]] On Behalf > > Of Ai Austin > > >> Sent: Saturday, August 28, 2010 4:59 PM > > >> To: [email protected] > > >> 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 > > >> [email protected] > > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > >> > > >> _______________________________________________ > > >> Opensim-dev mailing list > > >> [email protected] > > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > >> > > > _______________________________________________ > > > Opensim-dev mailing list > > > [email protected] > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
