<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Teravus,<BR>
<BR>
good of you to start working on this. But, I'm a bit confused as over what of these functions are part of the protocol, and what are 'percieved functionality' as in how things are organized on the server.<BR>
<BR>
I definitively think that the 'estate settings' packets will have to be assembled and disassembled from an array of sources, which implies that the client stack should have an EstateManager (or similar) that acts as an facade for the whole system, that is, it splits up get/sets requests and forwards them into separate backend services; permission manager, scenemanager, regionmanager, clientmanager et.c.<BR>
<BR>
This allows us to subclass and extend the EstateManager base so that we can support a variety of resolution schemes and data sources. One of them could be an true-to-SL implementation with hierarchy resolution, another read from an ini, yet a third from db, but for me, I'd like something that just says the same thing for all regions all the time.<BR>
<BR>
Best,<BR>
/Stefan<BR><BR><BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Tue, 18 Dec 2007 11:12:09 -0500<BR>From: teravus@gmail.com<BR>To: opensim-dev@lists.berlios.de<BR>Subject: [Opensim-dev] Estates Estates everywhere and nowhere to save<BR><BR>
<DIV>Hey all</DIV>
<DIV> </DIV>
<DIV>Going through and looking at the estate/region stuff we've currently got in place.. there's a fundimental difference from the client orgainization of 'estate and region'. Because of that there's also a severe lack of functionality. </DIV>
<DIV> </DIV>
<DIV>Currently, we've got one EstateSettings.xml file with 'set' values for all regions in our instance.</DIV>
<DIV>In addition, a few options are configurable per region in their respective region.xml files.</DIV>
<DIV> </DIV>
<DIV>Estates are logical organizational units that have a one to many relationship with regions.</DIV>
<DIV>There are many regions to one estate and every region is in an estate.</DIV>
<DIV> </DIV>
<DIV>Organizing it this way allows for a simple way to make configuration changes on all of the simulators you run (including regions on separate OpenSimulator Instances)</DIV>
<DIV> </DIV>
<DIV>It also allows you to section off certain portions of your map. (ParentEstate)</DIV>
<DIV> </DIV>
<DIV>Currently there's some real Old Crusty code surrounding the EstateSettings.xml file. You *can* save to EstateSettings.xml, but it's really ugly.. and you currently 'can't' save to your RegionInfo.xml files(so nothing persists).</DIV>
<DIV> </DIV>
<DIV>It's been proposed to put this information in a database and/or have it be asked when the sim loads for the first time.</DIV>
<DIV> </DIV>
<DIV>As far as Region vs Estate responsibility/relationship, what's the community concensus?</DIV>
<DIV> </DIV>
<DIV>If you change an estate setting, should it override a region level setting? (LLGrid does, do we want to?)</DIV>
<DIV> </DIV>
<DIV>Bear in mind that we've got cross over occasionally on the values.</DIV>
<DIV> </DIV>
<DIV>Some of the Nouns involved are;</DIV>
<DIV>BillableFactor<BR>EstateID<BR>MaxAgents<BR>ObjectBonusFactor<BR>ParentEstateID<BR>PricePerMeter</DIV>
<DIV>RedirectGridX<BR>RedirectGridY<BR>RegionFlags</DIV>
<DIV>SimAccess<BR>SunHour<BR>TerrainLowerLimit<BR>TerrainRaiseLimit<BR>UseEstateSun<BR>WaterHeight<BR>SimName</DIV>
<DIV>TerrainTextures (base1,base2,base3,base4)</DIV>
<DIV>Maturity</DIV>
<DIV>Maximum agents</DIV>
<DIV>Covenants</DIV>
<DIV>Estate managers</DIV>
<DIV>Estate Owners</DIV>
<DIV>UsedFixedSun</DIV>
<DIV>when to use the various terrain base textures</DIV>
<DIV>Estate level Banlists</DIV>
<DIV>Estate level allow lists</DIV>
<DIV>EstateID</DIV>
<DIV>ParentEstateID</DIV>
<DIV>BlockFly</DIV>
<DIV>AllowDamage</DIV>
<DIV>Restrict Pushing</DIV>
<DIV>AllowLandResell</DIV>
<DIV>AllowParcelJoin/Divide</DIV>
<DIV>Telehub settings</DIV>
<DIV>Disable scripts/Collisions/Physics</DIV>
<DIV>Sandbox Region</DIV>
<DIV> </DIV>
<DIV>Public Access</DIV>
<DIV>AllowDirect Teleport</DIV>
<DIV> </DIV>
<DIV>Eventually, Allowed Groups</DIV>
<DIV>(<Add more nouns here>)</DIV>
<DIV> </DIV>
<DIV>If we're using the LL grid as an example, then the following examples exist;</DIV>
<DIV><A href="http://wiki.secondlife.com/wiki/Estate_Visibility_Functional_Spec" target=_blank>http://wiki.secondlife.com/wiki/Estate_Visibility_Functional_Spec</A></DIV>
<DIV><A href="http://wiki.secondlife.com/wiki/Estate_Land_Sales_Functional_Spec" target=_blank>http://wiki.secondlife.com/wiki/Estate_Land_Sales_Functional_Spec</A></DIV>
<DIV><A href="http://wiki.secondlife.com/wiki/Estate_Manager" target=_blank>http://wiki.secondlife.com/wiki/Estate_Manager</A></DIV>
<DIV><A href="https://wiki.secondlife.com/wiki/Estate_Menu" target=_blank>https://wiki.secondlife.com/wiki/Estate_Menu</A></DIV>
<DIV> </DIV>
<DIV>I look forward to your response.</DIV>
<DIV> </DIV>
<DIV>Best Regards</DIV>
<DIV><BR>Tera</DIV>
<DIV> </DIV></BLOCKQUOTE></body>
</html>