[Opensim-dev] avatar system or similar

Fri Apr 11 13:33:31 UTC 2008

Jani,

There is already a proxy type implementation.  Check the 3Di load
balancing solution for that.  It allows you to move a region from one
server to another without interrupting the user.  This uses a proxy,
similar to that you described.

Also, like Charles said, we would greatly welcome your patches.  One
other thing to add is that the patches should be in small chunks, so
that it is easier to debug if there are any problems.

Thanks!
Adam J

On Fri, Apr 11, 2008 at 8:06 AM, Kurt Taylor <krtaylor at us.ibm.com> wrote:
>
>
> I totally understand your viewpoint, but I see this evolving differently. In
> the early days of the internet access, it was the access that was restricted
> via user accounts. As time passed, people realized that they just needed a
> network connection, not an account with Comupserve or AOL. The value in the
> web is the content, not the access. Locking down content and making access
> open to everyone, including hackers, became the focus. Hackers are not an
> account problem, they are a authorization problem (in theory).  As such,
> content that is not able to be open still requires a specific login to a
> specific web site, despite several efforts for us to use a global
> credentials system. That is, an Amazon account will still not give you
> access to IBM.com either.
>
> I feel like interoperability is the key. With islands becomming connected,
> there will evolve open, public places in a grid and regions that will
> require some additional credentials to get access to the content. Solving
> the global credential system, and in this case, a resulting centralized
> avatar, is well beyond the scope of the OpenSim project. The best we can do
> at this point is continue to have open discussions with other VWs.
>
> Kurt Taylor / Kurt Stringer
>
>
> > Date: Thu, 10 Apr 2008 10:39:15 -0700
> > From: Diva Canto <diva at metaverseink.com>
>
> > Subject: Re: [Opensim-dev] avatar system or similar
> > To: opensim-dev at lists.berlios.de
> > Message-ID: <47FE50C3.2070201 at metaverseink.com>
> > Content-Type: text/plain; charset="iso-8859-1"
>
>
> >
> > I also don't know much about the details of realXtend's design on this,
> > I only know the general goal.
> >
> > My thoughts about this are as follows: we want organizations to control
> > who visits their regions, no question about that. There will be
> > organizations (like role-playing games, for example) that will require
> > accounts with them for people to play, and that's perfectly fine. This
> > also happens on the web: if you want to "play" in facebook, you need to
> > get an account with them.  But there will be organizations who will
> > welcome visits from accounts in other worlds, or accounts served from
> > "identity services", which don't exist yet. As I said, from where I
> > stand, I see this as a *major* need. I'm working with a lot of people
> > who want to use virtual worlds like that. They want to build useful
> > services in 3D, and they need people to visit. If people need to get
> > accounts with them, the whole idea stops in its tracks at the station --
> > or else they do it in Linden Lab's grid.
> >
> > I don't see any need for *automatic* selection of one of several
> > possible accounts associated with a real world person -- that's a level
> > of sophistication that's unnecessary at this point and in the forseable
> > future. I think that goal is blurring the much simple things that can be
> > done relatively easily.
> >
> > What I see  is the need for identity services that are independent of
> > any particular grid. Here's the usage scenario:
> >
> > 1. People get accounts with one (or more) identity services. For
> > example, I (Crista Lopes) get an account in an hypothetical identity
> > service provided by VeriSignVW; that account is called
> > crista at verisignvw.com. Besides my ID, VeriSigVW gives me storage space
> > for my crista at verisignvw.com inventory.
> > 2. I login to some virtual world, say OSGrid, using that account. OSGrid
> > must accept avatars from VeriSignVW. Maybe OSGrid is more generic than
> > that; maybe it accepts accounts from any identity service that complies
> > with a standard ID protocol, TBD.
> > 3. As I visit regions in OSGrid, all comms with inventory and user go to
> > VeriSignVW.
> > 4. At some point I want to visit some other grid, say IBM's public grid.
> > I TP to it under my representation which is crista at verisignvw.com
> > 5. The IBM grid must accept avatars from VeriSignVW. If it does, swoosh!
> > there I go. If it doesn't, I can't TP to it. I must logout, and login
> > under some IBM account. The extra work of automatically selecting
> > between my VeriSignVW account and my IBM account is completely
> > unnecessary at this point. I can do that manually. But having the
> > ability to surf under one single account between grids that accept that
> > 3rd-party accounts is a major step forward.
> >
> > Michael Wright wrote:
> > > I haven't been able to find too much on how the RealXtend avatar
> > > system is really going to work. And while in some ways I think its a
> > > step in the right direction,  it also seems to limit a lot of things.
> > > I'm not so sure you should alway have the same avatar for everything.
> > > Or should completely cut the "region servers" out of the whole
> > > process. If I teleport to a region that has a role playing game, maybe
> > > my avatar should automatically change (at least clothes, but maybe
> > > body as well) to fit into that game. So the region has to be able to
> > > have some say over the avatar.
> > >
> > > I have the same sort of thoughts about inventory. While it should not
> > > be centralised, the regions do need to be able to (with permission) do
> > > certain things, like maybe a region gives you a extra set of folders
> > > for use in that region, but they disappear when you leave it. I am
> > > also not sure there should be just one inventory set for each user.
> > > Why not a number of sub sets that can be combined etc. Maybe the
> > > region could restrict access to only a certain set, which might be a
> > > set that it provides, when in that region; no space ships when in that
> > > serious business region.. Inventory really needs to swap to a more url
> > > based system.
> > >
> > > Also we need to remember not everything will be interconnected. There
> > > will be some applications (or possible grids) that want to be separate
> > > from everything else.
> > >
> > > So I don't think we should be forcing any centralised system on
> > > people. And yes from what I've read, I actually think the realxtend
> > > avatar system sounds too centralised, but that could be because I
> > > don't know enough details of what is planned. I'm not saying its
> > > wrong, it just doesn't fit all possible uses. So we need things to at
> > > least be modular.
> > >
> > > Having said all that, of course I think a lot of people and
> > > applications will want to have shared resources like these. Just we
> > > have to be careful in how they are implemented. And for opensim at
> > > least, that should be a open process/design that everyone can be part
> of.
>
> > Subject: Re: [Opensim-dev] avatar system or similar
> > To: opensim-dev at lists.berlios.de
> > Message-ID: <47FE50C3.2070201 at metaverseink.com>
> > Content-Type: text/plain; charset="iso-8859-1"
>
>
> >
> > I also don't know much about the details of realXtend's design on this,
> > I only know the general goal.
> >
> > My thoughts about this are as follows: we want organizations to control
> > who visits their regions, no question about that. There will be
> > organizations (like role-playing games, for example) that will require
> > accounts with them for people to play, and that's perfectly fine. This
> > also happens on the web: if you want to "play" in facebook, you need to
> > get an account with them.  But there will be organizations who will
> > welcome visits from accounts in other worlds, or accounts served from
> > "identity services", which don't exist yet. As I said, from where I
> > stand, I see this as a *major* need. I'm working with a lot of people
> > who want to use virtual worlds like that. They want to build useful
> > services in 3D, and they need people to visit. If people need to get
> > accounts with them, the whole idea stops in its tracks at the station --
> > or else they do it in Linden Lab's grid.
> >
> > I don't see any need for *automatic* selection of one of several
> > possible accounts associated with a real world person -- that's a level
> > of sophistication that's unnecessary at this point and in the forseable
> > future. I think that goal is blurring the much simple things that can be
> > done relatively easily.
> >
> > What I see  is the need for identity services that are independent of
> > any particular grid. Here's the usage scenario:
> >
> > 1. People get accounts with one (or more) identity services. For
> > example, I (Crista Lopes) get an account in an hypothetical identity
> > service provided by VeriSignVW; that account is called
> > crista at verisignvw.com. Besides my ID, VeriSigVW gives me storage space
> > for my crista at verisignvw.com inventory.
> > 2. I login to some virtual world, say OSGrid, using that account. OSGrid
> > must accept avatars from VeriSignVW. Maybe OSGrid is more generic than
> > that; maybe it accepts accounts from any identity service that complies
> > with a standard ID protocol, TBD.
> > 3. As I visit regions in OSGrid, all comms with inventory and user go to
> > VeriSignVW.
> > 4. At some point I want to visit some other grid, say IBM's public grid.
> > I TP to it under my representation which is crista at verisignvw.com
> > 5. The IBM grid must accept avatars from VeriSignVW. If it does, swoosh!
> > there I go. If it doesn't, I can't TP to it. I must logout, and login
> > under some IBM account. The extra work of automatically selecting
> > between my VeriSignVW account and my IBM account is completely
> > unnecessary at this point. I can do that manually. But having the
> > ability to surf under one single account between grids that accept that
> > 3rd-party accounts is a major step forward.
> >
> > Michael Wright wrote:
> > > I haven't been able to find too much on how the RealXtend avatar
> > > system is really going to work. And while in some ways I think its a
> > > step in the right direction,  it also seems to limit a lot of things.
> > > I'm not so sure you should alway have the same avatar for everything.
> > > Or should completely cut the "region servers" out of the whole
> > > process. If I teleport to a region that has a role playing game, maybe
> > > my avatar should automatically change (at least clothes, but maybe
> > > body as well) to fit into that game. So the region has to be able to
> > > have some say over the avatar.
> > >
> > > I have the same sort of thoughts about inventory. While it should not
> > > be centralised, the regions do need to be able to (with permission) do
> > > certain things, like maybe a region gives you a extra set of folders
> > > for use in that region, but they disappear when you leave it. I am
> > > also not sure there should be just one inventory set for each user.
> > > Why not a number of sub sets that can be combined etc. Maybe the
> > > region could restrict access to only a certain set, which might be a
> > > set that it provides, when in that region; no space ships when in that
> > > serious business region.. Inventory really needs to swap to a more url
> > > based system.
> > >
> > > Also we need to remember not everything will be interconnected. There
> > > will be some applications (or possible grids) that want to be separate
> > > from everything else.
> > >
> > > So I don't think we should be forcing any centralised system on
> > > people. And yes from what I've read, I actually think the realxtend
> > > avatar system sounds too centralised, but that could be because I
> > > don't know enough details of what is planned. I'm not saying its
> > > wrong, it just doesn't fit all possible uses. So we need things to at
> > > least be modular.
> > >
> > > Having said all that, of course I think a lot of people and
> > > applications will want to have shared resources like these. Just we
> > > have to be careful in how they are implemented. And for opensim at
> > > least, that should be a open process/design that everyone can be part
> of.
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>