[Opensim-dev] avatar system or similar

Sat Apr 12 00:20:06 UTC 2008

The answer, as always, is 'no single system will be the one' - OpenSim should be grow to facilitate authentication and resource transfer regardless of it happening via OGS2, SLOGP, Rex or thru some kind of directory service.

Now, OGS2 will probably be the reference implementation, since it's 'our' protocol, but we should strive to has an as flexible model for intercomm as so facilitate implementation of others.

We already know we have work to do in this regard; let's just all agree that our goal is not to create 'the' intercomm protocol, but rather a set of service interfaces and a reference implementation.

Very much the same as what we aimed for with the ClientStack; we should strive to be able to support multiple protocols both in the 'frontend' (various viewers) and in the 'backends' (various authorization and resource transfer protocols) - it should just be a question of identifying common and separate services and functions, one call at a time.

Leave it open for various sub-projects to work on their respective protocols separately, and use OpenSim to unify them.

/Stefan

Date: Fri, 11 Apr 2008 13:44:57 -0700From: cfk at pacbell.netTo: opensim-dev at lists.berlios.de; diva at metaverseink.comSubject: Re: [Opensim-dev] avatar system or similar

Its not at all clear to me which "universal avatar" system will be the one adopted. There are notions from SecondLife with Zero's SLOGP (Second Life Open Grid Protocol). The AWG (Architecture Working Group), IBM has some notions, other developers have notions and REX has notions.All of these need fleshing out  and discussion in the open. As we move forward with OpenSim, personally, I tend to favor the SLOGP notions over others as SecondLife has the greatest momentum. What others will favor, I do not know yet. But I do know that some amalgam of all the notions will eventually be the one adopted by OpenSim as we move forward in a world that has as much SecondLife compatibility as possible and uses their official client to reach the greatest number of users.Charles
----- Original Message ----From: Jani Pirkola <jpirkola at gmail.com>To: diva at metaverseink.com; opensim-dev at lists.berlios.deSent: Friday, April 11, 2008 12:28:13 PMSubject: Re: [Opensim-dev] avatar system or similarDiva,Your offer is greatly appreciated. As I mentioned a while ago, we are just now merging the newest OpenSim code to us, which makes the patching process back to OpenSim easier. We will have first (still buggy) version of the merged code available 14th of April, next Monday at our sourceforge SVN. We will continue to add patches as they appear to OpenSim to keep codebases aligned and we continue to fix and test things so that they really work. Mikko will start some patching as soon as possible.If you want to help us, Mikko can add you to the sourceforge project.Thank you!Jani 
2008/4/11, Diva Canto <diva at metaverseink.com>: 

OK, understood.If the realXtend programmers-extraordinaires could find a way of using a proxy, like 3di's  load balancing (or even their proxy +- as is), I think that would be a good thing.My main point is that having inter-grid TPs is a must for any serious=scalable purposes of virtual worlds (that's what I see from where I stand); you guys already have it, in some form, so there's no point in me or others re-inventing the wheel; but it's taking quite a while to integrate it with OpenSim -- there's been, what, 6 weeks, which is an eternity for this particular high-speed project. I think the reason why it's taking so long is a process mismatch: realXtend did substantial changes not only to the code but also to the architecture of OpenSim; OpenSim is all about a very rapid sequence of small patches. So let's break what you did in smaller patches so that it plays better with the OpenSim process. If you don't want to do that, I can try to take a look at your code and see how it could be chunckified/patchified/modularized more efficiently. I would *love* to see what you did integrated with OpenSim asap. 
Jani Pirkola wrote: 
Hi,The LL viewer is supposed to login only once and stay connected to that place for the whole session. If someone is willing to do "a voodoo server side component" that can act as a proxy between the client and different servers, then it might work. It just seems an awfully lot of trouble to just be able to use current LL Viewer. Maybe OpenViewer guys could also be interested to support the avatar architecture?Jani
2008/4/11, Cristina Videira Lopes <lopes at ics.uci.edu>: 

Can't wait to see that integrated with OpenSim!
I like your viewer a lot,  but do you think there is a way of restructuring this so that it can be used with the regular LL viewer? Why does this need your viewer at all? Is it because the login process requires additional cooperation from the client? I mean, I understand that the more fancy avatar appearance that you have requires changes in the viewer, but I don't see why the inter-grid TPs require a different viewer. Isn't there a way of separating the inter-grid TPs from the avatar appearance? Could you explain that?

Crista / Diva

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Jani PirkolaSent: Thursday, April 10, 2008 2:29 PM 
To: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] avatar system or similar

Hi,

1)      Will VeriSign or Yahoo – or whomever – be able to set up these kinds of account services?

Yes that is right. 

2)      Does it work more or less the way I described my usage scenario? That is, will I be able to go from OSGrid to the public IBM grid under crista at verisignvw.com, assuming both grids accept verisignvw accounts?

yes just like that. You get also possibility to change your account in the teleporting process in case you know that another grid is not accepting your example crista at verisignvw.com account (actually this happens if you teleport to Second Life). 

3)      Does this require the use of the realXtend viewer or can this be used with the standard LL viewer?

Currently only realXtend viewer can be used, but I wish that in the future there will be more support for this architecture. We maintain the realXtend viewer so that it can be used to access also SL servers or standard OpenSim. The avatar appearance from avatar storage can only be seen by others on realXtend servers. The architecture needs support from both server and client. 
Jani

Crista / Diva

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Jani PirkolaSent: Thursday, April 10, 2008 1:20 PMTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] avatar system or similar

Hi,Some comments how realXend has implemented things:

2008/4/10, Michael Wright <michaelwri22 at yahoo.co.uk>:
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. 

The current realXtend login process gives a control point for region servers as well. When a user logs in to a region, the viewer sends URL to user's avatar storage. The region then sends that URL t other viewers so that other user's can see each other's avatars. It is possible that in e.g. a strict role playing world, the region uses it's own avatar storage which stores a special avatar for just that user. Then the region server sends URL to that avatar storage instead of the one that viewer sent to the region. If we want to get really smart here, it would be also possible to combine something from the user's regular avatar to the role playing game avatar to achieve nice results... e.g. using face form from user's regular avatar but otherwise using region specific body and clothes. 

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. 

We are just thinking how to build all this in realXtend. Currently we have thought that each user will have a region specific inventory and a personal inventory. The personal inventory is stored at avatar storage so it will travel with the avatar. 

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. 

Currently realXtend components have been designed so that there are no centralized control points, it would be really a bad planning to build such an architecture on that kind of centralized assumptions. In realXtend architecture, everyone can set up their own avatar storages and user authentication services and decide to trust or not to other user's authentication services. If a virtual world hosting company wants to make a completely walled garden solution with realXtend, that is also possible. They can set up their own avatar authentication and storage and trust no-one else's authentication server (there is a basic allow/deny setting for this). 

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. 

A team of people almost always reaches better solutions over individual. All the different use cases should be covered in a great care. I hope that realXtend initiative with the distributed avatar architecture is being refined with the OpenSim community involvement. I am sure that there are still many things that need addressing. The realXtend code is available at http://sourceforge.net/projects/realxtendserver/ and as I mentioned in my earlier mail, we will have a new version, which is based on current OpenSim, soon available.Best regards,Jani PirkolarealXtend program manager 

Sean Dague <sean at dague.net> wrote:

On Thu, Apr 10, 2008 at 08:50:33AM -0700, Diva Canto wrote:> Hi,> > What happened to realXtend's "avatar system"? Is it being integrated > with OpenSim?Short answers. I don't know, and no. The process for code coming intoOpenSim is to put a patch in mantis. I haven't seen any proposedpatches in this area in mantis.> From where I stand, that, or something like that, is a major > architectural requirement for virtual worlds to get serious. Without the > ability for people to get an identity+inventory that they can port > around through different organization's grids, this is not going to be > that useful. I see a lot of interest from organizations to set up their > own virtual worlds under their control (so, their own grid'ed regions), > but if people have to get accounts with them to visit, this is just not > going to work for serious usages - period.Hence you've created the paradox. :)* We want everything connected* We don't want to trust a single authoritative source for info(otherwise you'd be on Second Life)Honestly, this is a hard problem to solve, and one that seems a bitbeyond the current scope. That being said, implementations and researchin this area which work with OpenSim are always welcomed.> I understand there's a ton of stability work to be done, but this > particular architectural decision is really important, even > (especially?) at this early stage; we all trust stability will happen > over time.> Is there anything that I can do to boost the efforts in that direction, > besides sending this email?Sample peer based User services that allow cross talk would be useful.The moral equivalent of OpenID for virtual worlds (because you need morethan just what openid provides).-Sean-- __________________________________________________________________Sean Dague Mid-Hudson Valleysean at dague dot net Linux Users Grouphttp://dague.net http://mhvlug.orgThere is no silver bullet. Plus, werewolves make better neighborsthan zombies, and they tend to keep the vampire population down.__________________________________________________________________
_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev

Yahoo! for Good helps you make a difference
_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
 _______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev  _______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
-----Inline Attachment Follows-----_______________________________________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080412/ee537f51/attachment-0001.html>