<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>I think we have two "groups" discussions and perceptions going on.<br><br>1. "Group Communication" - This involves text based chat windows with messages forwarded to all the members of a group. <br><br>2. "Group Permissions" - This involves how a member of a group may terraform region parcels and edit/transfer objects owned by a group.<br><br>My personal focus is on "Group Communication" as I think this is a way to help us move forward in our grid-based communication and away from the current one->one IM scheme implemented. <br><br>But, I respect that there is a second focus.<br><br>Perhaps we can try to make our "groups" discussion a tiny bit more focused as I am getting confused about which piece folks are talking about and hence, which piece should be where.<br><br>Charles<br></div><div
style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Diva Canto <diva@metaverseink.com><br><b><span style="font-weight: bold;">To:</span></b> opensim-users@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Monday, April 6, 2009 8:50:07 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Opensim-users] Groups Implementation Discussion (Ai Austin)<br></font><br>
<title></title>
Whatever the group system is, just please keep it separate from region
servers at a healthy distance. I would go as far as suggesting that the
administration actions in groups should not be accessible via the raw
LL viewer because it is a recipe for entanglement. Have all that
administrative work done via web/http, which then other viewers can
integrate back if they want. <br>
<br>
Dr Scofield wrote:
<blockquote type="cite">
<pre>Ralf Haifisch wrote:<br> </pre>
<blockquote type="cite">
<pre>*gg*<br><br>Sure - but unless you have a scalable and robust load balanced topology as<br>e.g. notes/domino, you can avaoid some trouble by having an advance.<br><br>The trouble to avoid is enumeration.<br><br>Lindens did a "one fits all" group thing.<br><br>While security groups are ACL based, they still need some kinda enumartion.<br><br><br>So, at the time people had more and more groups and more and more members<br>have been in that group and sending group IMīs, the system degraded. If<br>this would have been limited to communication it would have been discomfort<br>- but getting the enumeration in groups getting stale, so influence in<br>collaboration, it was a pain in the neck.<br><br>The advantage would be the goal Charles did outline: move on to the next<br>frontier. You could keep compatibility on one (security) while setting up<br>a more advanced (maybe XMPP, wich could be a voice basis as well) solution<br>for the other
(communication).<br><br>Besides that - yes, collaboration needs communication. Call me old style -<br>I still prefer to be able to access files, portals and print over email<br>@work. I can still pick up the headset. So I would prefer to isolate the<br>communication from security for availability means, as well.<br> </pre>
</blockquote>
<pre>i would argue that we first of all need a proper group system, then we can make<br>use of the group system for various other purposes, such as access control,<br>modification rights, communication purposes.<br><br> DrS/dirk<br><br> </pre>
</blockquote>
<br>
</div></div></div></body></html>