<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Yes, again; we should implement this as an interface, so that I, for one, can sidestep the whole thing and supply settings based on hard-coded algorithms; Adam can do his ini thing and sdague et al his db based thingies.<BR>
<BR>
plzkthxbai,<BR>
/Stefan<BR><BR><BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Wed, 19 Dec 2007 12:04:33 -0600<BR>From: james.stallings@gmail.com<BR>To: opensim-dev@lists.berlios.de<BR>Subject: Re: [Opensim-dev] Why we shouldnt support Estates<BR><BR>I think this is just why the module architecture is a great thing, to allow us to differ from SL in terms of policy and architecture as we see fit without breaking compatibility.<BR><BR>Cheers,<BR>James aka Twitch/Hiro<BR><BR><BR>
<DIV class=EC_gmail_quote>On Dec 19, 2007 10:43 AM, Stefan Andersson <<A href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</A>> wrote:<BR>
<BLOCKQUOTE class=EC_gmail_quote style="PADDING-LEFT: 1ex">
<DIV>On a side note, this is also implemented in the Reg Api that third parties can use to auto-register their members onto SL; there is an option to confine the newly registered user account to an estate owned by the registrator; ie to create a 'walled garden' within SL. <BR> <BR>/Stefan<BR><BR><BR><BR><BR>
<BLOCKQUOTE>
<HR>
Date: Wed, 19 Dec 2007 11:21:10 -0500<BR>From: <A href="mailto:teravus@gmail.com">teravus@gmail.com</A><BR>To: <A href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</A> <BR>Subject: Re: [Opensim-dev] Why we shouldnt support Estates
<DIV>
<DIV></DIV>
<DIV class=EC_Wj3C7c><BR><BR>
<DIV>There's another purpose for estates also. </DIV>
<DIV>Grid separation, on the same infrastructure.</DIV>
<DIV> </DIV>
<DIV>The EstateID, and ParentEstateID Property</DIV>
<DIV> </DIV>
<DIV>Basically, this is what LL uses to separate the MainGrid from the Teen Grid while not significantly increasing the hardware or configuration requirements.</DIV>
<DIV> </DIV>
<DIV>All Users have a EstateID Property.. that corresponds to the regions and users that they can interact with and see.<BR> </DIV>
<DIV>Example</DIV>
<DIV>*One main grid has an estateID 0. All users to this grid are created with an estateID 0 property.</DIV>
<DIV> </DIV>
<DIV>*A teen grid has an estateID 2. All users who sign up for this grid are created with an estateID 2</DIV>
<DIV><BR>When users pull up the map, they can only see the regions where the EstateID or the ParentEstateID = their user estateID property.</DIV>
<DIV> </DIV>
<DIV>This also extends to Instant Messages and teleports.</DIV>
<DIV> </DIV>
<DIV>'God Users' can see, interact with, and move in between all EstateIDs</DIV>
<DIV> </DIV>
<DIV>I can see this being used by a service provider to give users their own 'grid'. </DIV>
<DIV> </DIV>
<DIV>My purpose for mentioning this is to make sure that this functionality is considered, *not to rehash the idea of estates*</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><SPAN>On 12/19/07, <B>Adam Frisby</B> <<A href="mailto:adam@gwala.net">adam@gwala.net</A>> wrote:</SPAN>
<BLOCKQUOTE style="PADDING-LEFT: 1ex">Pardoning the slightly inflamatory subject line - allow me to clarify.<BR><BR>The "Estate" system as currently implemented by Linden Lab is shall we <BR>say ... imperfect?<BR><BR>Right now -- as it stands, an estate is a collection of regions under a<BR>common name sharing a few properties:<BR><BR> * Estate Owner is shared across all regions in the estate<BR> * Estate Managers are shared across all regions in the estate <BR> * Estate Bans are shared across the estate<BR> * The time-of-day is shared across all regions in the estate<BR><BR>Frankly - I think this is mediocre at best, very limiting at worst.<BR><BR>For example, say you have two seperate groups of regions that want to <BR>share a single ban list? RBL's seem to indicate people will want to do this.<BR><BR>So - what's the solution? Remove abitrary groupings and make each of<BR>these something independently configurable, for example: <BR><BR> Ban List<BR> Rather than have a single list shared among X regions,<BR> allow regions to be configured to have a remote banlist<BR> - some kind of URL where they can POST / GET queries <BR> about user status. Put this functionality into a<BR> BanModule-type RegionModule so it can be swapped or<BR> configured independently at whim.<BR><BR> Estate Managers<BR> Similar to the above, add support in the permission<BR> manager for looking up the permissions of a individual<BR> user from a remote URL or address.<BR><BR>Now, the PermissionsModule and BanModule should respond to messages from <BR>the client sent by the estate tools -- but on the backend we have a much<BR>more configurable situation which is more suitable for large scale<BR>deployments.<BR><BR>Regards,<BR><BR>Adam<BR>_______________________________________________ <BR>Opensim-dev mailing list<BR><A href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</A><BR><A href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target=_blank>https://lists.berlios.de/mailman/listinfo/opensim-dev </A><BR></BLOCKQUOTE></DIV><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>Opensim-dev mailing list<BR><A href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</A><BR><A href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target=_blank>https://lists.berlios.de/mailman/listinfo/opensim-dev</A><BR><BR></BLOCKQUOTE></DIV><BR><BR clear=all><BR>-- <BR>===================================<BR>The wind<BR>scours the earth for prayers<BR>The night obscures them </BLOCKQUOTE></body>
</html>