[Opensim-dev] Global identifiers

Toni Alatalo antont at kyperjokki.fi
Thu Sep 2 16:23:13 UTC 2010


On ma, 2010-08-30 at 23:46 +0200, Melanie wrote: 
diva at metaverseink.com wrote:
> > I know. But what about when we get to 1.1 and we want to start bridging 
> > the social network with other non-VW social networks? Their external 
> > references look different than the ones we are talking about here, and 
> > we will need a local UUID for those; where do we stick it?
> > ...Should we cross that bridge later?
> I'd say let's burn that bridge when we get to it. We can't
> anticipate what will be needed and would wind up with useless junk
> like the load we cleared in the past year.

we have used email style global identification of users.
account at service in the old rex auth ('global av system')
and openid in the current thing (using the old CB stuff for it)
.. though the openid things are .. well they've showed to me as URLs at
least, don't even know how it works *embarassed* . i guess you know how
it works when people use Facebook accounts etc (people do/did that on
sciencesim, right?)

i'm not sure if this bears any effect to this discussion, but have been
wondering along the thread.

and someone mentioned XMPP - that uses the email type, right? but of
course it's about comms contact, not (meta)data about object creators
etc.

initially my reaction of course was that URLs and perhaps also the other
URIs i.e. URNs are the thing here, and i guess you folks have reached a
good consensus about the display name caching and all .. just wanted to
remind of those examples of existing global user IDs which we are using.

the old rex auth, with a separate auth server that's not related to any
world (grid), perhaps can be like a grid from the point of these grid
protocols .. it's just a grid without worlds, only users and avatar
data :) (the global av system works so that the av assets are on an av
server, which is just a web server from which the viewers fetch the AVs
they see). and perhaps openid providers can/could be thought of
similarly? gmail being my 'home grid' when using a google account, eh?

with the webdav inventory we've been using with cable beach, the old
special AV storage is deprecated. instead, 'cause the inventory is also
just a web (http) server anyway, there is a special folder in the inv
called 'avatar' which is exceptionally world readable. and somehow this
ties in with the openid auth but i don't even know how exactly. i figure
that is unrelated to the creator id references discussed in this thread,
though.

> Melanie

~Toni

> > Melanie wrote:
> >> I think we already have a perfectly good field, which is a UUID for
> >> local users and a URL for remote ones.
> >> 
> >> Melanie
> >> 
> >> Serendipity Seraph wrote:
> >>>  On 8/30/10 2:09 PM, diva at metaverseink.com wrote:
> >>>> 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.
> >>>>
> >>> It seems more reasonable in a distributed system to say that an X is an
> >>> X - a User is a User, whether they originally were instantiated on a
> >>> local or a remote system.   So I would go for collapsing the two as much
> >>> as possible as a matter of policy.  Otherwise freedom to move between
> >>> nodes in the system is more limited and there is more special case logic
> >>> to deal with.    But that is speaking from a general distributed
> >>> computing perspective.  There may be many Opensim details that make that
> >>> seemingly ideal position in practice rather naive.
> >>>
> >>> - s
> >>>
> >>> _______________________________________________
> >>> 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