Yes Yes it's beginning to sink in. So much cleaner. I think hopping between independent server processes by link works just fine. I'm thinking a developer could even program an object as a link so that as you travel through the object on one server and then appear in a matching object in the other server to appear like travel over a continuous connection.
A hyperlink based approach allows for complete flexibility rather than being locked into a two dimensional grid. With the hyperlink system I could have "Castles in the Sky" or Underworlds controlled by a completely different organization. Any topology is possible, even physically impossible ones. Ok, on view-abilty. We don't need to prevent view-ability per se. We just have to keep people out of places they should not go. Tell me if this approach seems viable to you. In the scene there is a building object with an entryway blocked by a door object. The door object is owned by the admin or another user. An avatar/user approaches the door object and attempts to open it. The door object gets the login ID from the avatar and queries LDAP. The avatar/user enters their password. If they are authentic the door object moves out of the way and allows the avatar/user to enter the building object and of course see content inside. If the avatar/user doesn't auth-out the door object stays put they are prevented from entering. Assuming there is security in place for changeability and execute- ability, and an avatar has some way to be connected with a userid then I think this would work. It may not be completely un-hackable but we just want to keep one student out of another's work. We'll be handling the more sensitive material using a 2D web based system, not Moodle but like it. It actually uses OpenKM for documents. What I've been describing so far is the big picture for our group project. As a first test for the group I plan to teach a completely introductory programming course in Python using a VW. I may or may not have an online classroom system for the course. The students wouldn't be writing modules for the overall simulation, just programming object scripts and adding interactive content. Very simple programs but how much more captivating to manipulate 3D objects instead of console IO. Last year I did the same class using Python in eclipse, blender, and Panda3D. Last Spring our project group started looking at Opensim and we did some basic training. At that time I was looking at using LSL and dropping blender. I'd like to use blender again this year and Python as well, hence the interest in Tundra. I may be not understanding the underlying model completely here so excuse me if I'm coming out of left field. Thanks again. Also the Entity Component paper was very helpful in getting me up to speed. I think it get's to the point well. I'm a sucker for an elegant general solution. Can I share it with a couple of folks in our group? George On Jul 1, 5:50 pm, Toni Alatalo <t...@playsign.net> wrote: > On Fri, 2011-07-01 at 12:56 -0600, George Sellman wrote: > > I'm glad my timing is good. A quote from the A-team "I love it when a > > plan comes together" > > :) Just a (quick) reply to a few points now, is getting late here: > > > You can see that for classroom type activities we need > > security/ownership etc. Specifically, it would be great to control > > I've come to learn that, yes. For long it was a mystery to me what > MOODLE is, and what the SLOODLE SL integration for it is, and based on > some video it seemed that it was basically a way to have groups and > permissions etc. to manage object ownerships and rights etc. (if someone > doesn't know, MOODLE is an open source system especially for education > orgs). So indeed permissions seem to be essential in schools. > > > viewability, changeability and interact-ability on an individual > > user/owner basis or even with groups. Kind of like readable, writable, > > executable in the Unix/Linux file system. So, we would like to be > > able to keep avatars from entering/viewing areas that they don't have > > permission to see. As well as, of course, modifying or interacting > > with things they don't have permission to play with. > > Controlling viewability is not in the current plan, and AFAIK hasn't > really been in the use cases so far. It is possible, albeit on the > tricky side. I'm not sure if it's actually a good design, but possibly > so, and certainly an intriguing idea. > > We talked about it a bit with Jonne on IRC now (#realxtend-dev on > freenode) > > 01:53 < Pforce> i was thinking how to do that object hiding for certain people > 01:53 < Pforce> possibly not send the entities at all to those clients > 01:53 < Pforce> but that would require scenemanager changes afaik > 01:53 < Pforce> have similar AboutToSend(Endity*) > 01:53 < antont> i'm gonna reply that the object hiding is simplest to do by > using different server instances > 01:53 < Pforce> wouldnt it? > 01:53 < antont> but yes that'd work too, was thinking about it > 01:53 < Pforce> i dont think it hurts to add those either > 01:53 < antont> i'm not sure if we wanna that though > 01:54 < antont> yah certainly someting to consider > 01:54 < Pforce> full control for server sec policy :P > 01:54 < Pforce> i mean if its just signals again > 01:54 < antont> yah if there is a valid use case and someone sends a patch, > hard to see why we'd reject it > 01:55 < antont> but i'm not sure if that dir is a good solution in general, > having different entities in the same place for diff clients > .. well can be nice, e.g. in TOY teacher mode you'd have extra things around > 01:56 < antont> and would make it kind of nice that you only need one server, > one scene, and can still have groups that don't see each others > things > 01:56 < antont> but e.g. a teacher can see them all at once > > > It looks like the modifying/interacting on an entity by entity basis > > is where you're going right now which is a great improvement over > > regions. Complete view-ability control would be nice for our use case > > though. > > The SL permission system also has modifying on an entity by entity > basis. Objects have owners, at least, and are there group rights too? > > There is actually an on-going discussion on the opensim mailing list > about controlling viewability -- someone wanted to make it so that > certain textures show only to certain users. It's not currently > supported for normal objects in Opensim, Justin estimated implementing > it would take a lot of hacking around, perhaps not really feasibly > there. But someone else told that some parcel media settings can already > be used to control that for some media streams or something. > > > Tundra. Not exactly permissions related. I'm just trying to get > > familiar with the Tundra model and implementation. It looks like > > Have you seen the EC article btw, "An Entity-Component Model for > Extensible Virtual > Worlds"https://github.com/realXtend/doc/blob/master/arch_article/simple.pdf?... > > It's in final editing now (the IEEE magazine editor emailed a restylized > version that I must review by next Thursday, I think goes to press then > so finally gets finished for now). > > > there are significant performance improvements over opensim and I'm > > liking the idea of linking to other peoples worlds. We are also > > planning to run this in the cloud with different folks controlling > > their own areas. Is it possible for a single Tundra server to run > > across multiple machines now or in future? At the risk of being > > Opensim-ish I'm thinking grid mode, but I'm guessing you have another > > way of approaching this. > > We don't have an all encompassing solution to that fixed, and I suspect > there very well may be all sorts of different configurations. Also with > Opensim you have various configurations, like normal grids and > hypergrid, and I guess others would be possible to add. Ah and Intel > folks finally put the distributed scenegraph thing in now, for load > sharing / scalability. > > So to answer your question, if you replace 'single Tundra server' with a > 'single Tundra world', and use a bit of imagination to fill the gaps, > then it's a yes :) > > That is: simplest way now to host different areas controlled by > different people is to run a separate server process for each area. An > independent scene. Similar to how in SL and Opensim there's a sim > process for a region. > > Then you can teleport between the areas, which is simply logout & login, > but can do the auth so that there's no re-authentication but single > sign-on. This is similar to the web, just using the tundra protocol > instead of http .. sessions instead of document retrieval. So you can > get something similar to SL / Opensim grid mode, which basically is > about using the same user/auth server and inventory on several sim/scene > servers. > > We don't currently have 'multiregion' support, handling multiple > simultaneous server connections in the client, which is what slviewer > does to give an illusion of a single seamless world on those separate > servers. It is possible to add, but not always necessary and certainly > not the simplest thing. Folks at Chiru have been working on multiscene > support for other reasons, that work may result in some groundwork for > this too. Actually an early buggy version of that branch there put > things from several Tundra connections / scenes to a single Ogre scene, > which sure looked fun enough :) > > We've had some talks about supporting multiple scenes in one server, for > scalability reasons. The current bottleneck for large dynamic worlds > and/or a lot of users is network bandwidth, so partitioning scenes to > areas and/or doing so-called interest management to optimize what > information to send to which client etc. are coming to the table. That > needs at least a little similar mechanisms than visibility control for > your usage rights scenario -- new functionality in the Scene and > SyncManager to control what is sent to whom and when (now everything is > sent to everyone on the server, always and immediately). > > > Hope I haven't over stepped. We've got developers and funding. If > > you'll have us we would like to contribute anyway we can. > > Certainly no overstepping here -- this is exactly the kind of stuff we > are here for! > > Contributions in these areas would be very welcome, I think all the > current developers have their plates full with other things so far. I > recall ENNE.es will need scalability improvements at some point, and > chiru.cie.fi has been looking into the interest management biz for > bandwidth optimization reasons (they do research / work on enabling > mobile use of VWs / MMOs), but I don't think there are any concrete > plans yet. > > Perhaps you could get quite far with the current tech too, just using > different server instances for the different areas and having tundra:// > hyper(?)links between them .. or some sort of map of area selection > menu? > > I'm sure you'll encounter also other areas in need of improvement when > put students to implement apps in py over Tundra or something (is that > the plan, do you use py in teaching programming or something?) .. I > don't know what, but we can't have all the basics covered perfectly yet. > So perhaps good to investigate that before dive into fancy visibility > controls? Or who knows, that might be quite simple to implement and > quite powerful .. and the Core API and py&js support etc. do provide a > lot already. > > > George > > ~Toni > > > On Fri, Jul 1, 2011 at 1:17 AM, Toni Alatalo <t...@playsign.net> > > wrote: > > On Thu, 2011-06-30 at 16:42 -0700, sellman wrote: > > > Wondering.... > > > Will permissions/security be added to Tundra in > > upcoming > > > releases? > > > Perfect timing! > > > If you look on the -dev list, and recent commits, you'll see > > that we > > agreed on the design for it a couple of weeks ago, and I have > > since > > implemented the first part of it. > > > Completed the first step yesterday actually, the signal now > > has the user > > connnection as a parameter so you can treat different users > > differently. > > > So that is already in and coming to next release. Would be > > great if you > > could start using it straight away, if you can build your own > > development version. > > > > If not, could accounts/permissions be added to Tundra > > by creating > > > our own simple Python module? How complicated? External > > > authentication looks fairly direct. > > > We've continued with that same design: the core has qt signals > > as hooks > > that 3rd party c++/py/js code can use to implement > > accounts/permissions > > how it wants. > > > This is how I've tested it while developing, a js func that > > denies all > > remote editing: > > > > https://github.com/realXtend/naali/blob/tundra/bin/jsmodules/apitest/... > > > s.AboutToModifyEntity.connect(function(change, user, entity) > > ... > > read more » -- http://groups.google.com/group/realxtend http://www.realxtend.org
