Talk:Central Services

Topology

• I can't be the only one who thinks it would be awesome to stack regions on top of each other. Along the same theme, how do we handle region boundaries with different sized regions? I think I heard OpenSim 'can' do this, if so, how is that done ? --otakup0pe 09:25, 16 September 2007 (PDT)

• There is one extremely important item missing from the Central Services picture: Proxy Caches. See my comments on the Discussion page of Zha's Desiderata page describing the AWG meeting [[1]]. Without this, the residents of large grids will not be able to visit smaller grids without "Slashdotting" them utterly, so large grids will become insular or only connect to other large grids ... not a recipe for success. --Morgaine Dinova 05:02, 24 September 2007 (PDT)

Zha's addon

• Here's an interesting way to think about topology... Which I think offers a lot of flexibility. Building a connected world out of individual regions, really requires only a few fundamental services. You need the ability to serve out object and avatar information to adjacent simulators and clients, so that you can see across the boundaries, you need to handle motion across the edges, you need a way of determining what edges connect, and lastly, you need, some behavior, inside the region. to know when to use the other two services and the topology information.

So, the primary service is "Tell me what an agent looking into your region from relative coordinate X.Y.Z needs to know" This is pretty much the Child Agent in SL today, I expect. That gets coupled with a region knowing its local edge portion "coordinate description of a portion of the edge of a region" is adjacent to another regions "coordinate description of the edge portion" The final bit is just the "Agent X" is arriving at your "edge coordinate" message.. to do hand off. A nice optimization, might be "Agent X is nearing your edge coordinate...."

This leads to one other service, which is the utility which allows regions to register where they are in relationship to each other, and find out where they are.

Note, that done properly, this permits very different tesellations of regions. As long as we can reasonably assemble a coherent geometry out of it, the services don't care. Also note, that if we allow odd non-realistic effects, the services support that. A "portal" could be in the middle of a region, such that, Looking out, through a "gate" shows not the local land but a view into another region, and walking through the gate, in one direction does a "walking handoff" to the next region.

- Zha Ewry 9-25-2007

• Adding a bit more to "Tell me what an agent looking into your region from relative coordinate X.Y.Z needs to know":

Note that it's not functionally any different making these requests from inside or outside of that region --- both types of request need a source coordinate reference for spatial relevance sorting. As you say, only the relative coordinate w.r.to the target region's space really matters, not the absolute coordinate within the requesting region. However, given that portal apertures can be moved around at will and even animated (mirrors come to mind), note that both a coordinate and a viewing vector would be required if the target region is to supply direction-sensitive data. (But see below ... delivering highly specific occupancy data may be inappropriate.)

The information returned is not necessarily culled as a function of distance either: for example, a mountain on the far side of a region would become visible even when you approach the near side. It still needs to be presented to the agent for passing to the client as proxy and/or sent directly to the client. Despite the large topological distance to the mountain, a modern client will still display the remote entity, with CLOD and other techniques manipulating the rendering resolution appropriately.

It's worth noting that the above approach may rapidly become obsolete, if it is not so already. The target region occupancy is not a large body of data in the context of today's machinery (only the per-object data really bloats it up), so it may be quite efficient for all occupancy data to be delivered in one fell swoop if the target region finds that best. In other words, the supplied relative coordinate is really only a heuristic hint to the target region.

Certainly we don't want regions to be doing precision culling and clipping --- under the current static model, region servers don't scale, so this work must be done by the clients, which always scale linearly (or higher, with multicore). What's more, it's most definitely the client's choice which objects to process further for viewing, so region occupancy information supplied by the target region should never dictate that all the supplied occupants must be fully retrieved. Similar considerations apply for requests from the agent, in that only a few aspects of objects in the target region will be relevant, eg. boundary box information. --Morgaine Dinova 07:00, 25 September 2007 (PDT)

• PS. Small point: note that edges of target regions are only a special (but common) case of region adjacency. A portal in particular can provide access directly into the interior of a target region, and in most cases would do exactly that. --Morgaine Dinova 06:41, 25 September 2007 (PDT)

Security

I'd like to understand the Central Services a bit better in the context or running inside an Intranet. Companies can not use Second Life to its full potential because of security concerns. There is certainly a business case for keeping a region and all its comunication traffic inside a Intranet that the comany can control. An avatar could go out into the rest of SL but only those inside the Intranet could access the region inside the Intranet.

This seems doable except for maybe the Central Services (specifically Identity). How will the architecture be done so that companies feel secure? Will Central Services create a problem here?--Burhop Piccard 10:43, 4 October 2007 (PDT)