Hurliman, John wrote:
My interpretation (please correct me if I'm wrong) is that there is rough consensus on the overall strategy, but an open question of how to encode global identities when cross-grid communication (or out-of-grid archiving) happens.

That's what's going on.
Up to now, all global identifiers (that already exist) have been volatile; nothing has persisted. As I found myself writing code that would inject global identifiers into a DB table, I thought we should all talk about the form of such identifiers.

There is probably also a hidden question of how to mark a local account as 
linked to a foreign identity, which may solve the friending issue. If I am 
friends with your avatar and we are both on grid B but your avatar actually 
originated from grid A, that link in the profile is what can tip off the 
presence service to try a remote presence check (assuming the user is not 
online in the local grid). My only interest in these low level questions like 
how the global identifiers and profile links look is what the final decision is 
so I can implement it in the OpenSim SimianGrid connectors.

Well, we distinguish "user accounts" from "grid users" -- these are 2 different interfaces, although implementers may decide to collapse them. But they are different concepts. User accounts are the locally-registered users; in some cases, like for example, the UCI grid, there's only some people who can get accounts there, namely people associated with the university. Grid users are users that are referenced by things that happen in the grid. So we already have an interface for that, although now I'm thinking that perhaps we need to separate its UserID field into 2 things: a local UUID and a reference to the external name. And I guess that's my main issue at this point.


John

-----Original Message-----
From: [email protected] [mailto:opensim-dev-
[email protected]] On Behalf Of [email protected]
Sent: Monday, August 30, 2010 1:36 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Opensim-dev] Global identifiers

I have different answers than Melanie.

An open question with this approach is whether you need to use global
identifiers when dealing with cross-grid scenarios, or whether there is
always enough context to derive a global identifier. Some examples:
* A HyperGrid user is teleporting from grid A to grid B. Does grid B
have enough information to build the global identifier "gridA/user"?

Yes. It already does that on the spot. We don't need persistent global
identifiers for agents.

The issue we are now talking about is if someone in grid B makes
friends
with this user. In this case, we need to add an entry to grid B's
Friends service referring to an external user, and vice-versa. That's
when we need global identifier for this user (not its agent).

* A HyperGrid user rezzes an object into grid B that exists in their
inventory on grid A. The object has a creator that is unrecognized to
grid B. Should grid B pull the creator profile from grid A (which may
actually be storing a local copy of the real creator identity from grid
X)? Note that this isn't a question about trust because we're already
trusting grid A to provide creator information for the object, it's
just about where we pull profile info from.

Yes, it should. And since the code that does that is exactly the same
code that prepares inventory items for archiving, this should be no
different than archiving itself.

* An OAR file is loaded and contains an unrecognized identity. Should
identities in OAR files be encoded as global identifiers, or a header
added to the OAR file to say "all of this content came from grid A", or
the full profiles of all the identities in the OAR embedded right into
the archive?

I don't think it can be bulk in the general case, although that could
be
option in some cases. I'm looking at my inventory right now and it's a
rainbow of stuff I got from all sorts of places.
_______________________________________________
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

Reply via email to