<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
For any actions/decisions to be made about groups of people, you need,
first of all, and as DrScofield says, a group system. That is, you need
a system that supports the concept of "group" and allows the
addition/removal/update of "principals" from those groups. This system
is likely embodied in a server that then is accessed by the several
interested components (regions and other clients) to perform several
group-related actions like communication and access control. <br>
<br>
The administrative interactions with the group service
(add/remove/update) can be done in several manners. One of them is via
the raw LL viewer, with the LL viewer floaties. But that's not the only
way -- it can be done via the regular web, too. Just think of a service
similar to what you use for osgrid account access.<br>
<br>
Charles Krinke wrote:
<blockquote cite="mid:51879.43463.qm@web82606.mail.mud.yahoo.com"
type="cite">
<style type="text/css"><!-- DIV {margin:0px;} --></style>
<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
face="Tahoma" size="2">
<hr size="1"><b><span style="font-weight: bold;">From:</span></b>
Diva Canto <a class="moz-txt-link-rfc2396E" href="mailto:diva@metaverseink.com"><diva@metaverseink.com></a><br>
<b><span style="font-weight: bold;">To:</span></b>
<a class="moz-txt-link-abbreviated" href="mailto:opensim-users@lists.berlios.de">opensim-users@lists.berlios.de</a><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:
</pre>
<blockquote type="cite">
<pre>*gg*
Sure - but unless you have a scalable and robust load balanced topology as
e.g. notes/domino, you can avaoid some trouble by having an advance.
The trouble to avoid is enumeration.
Lindens did a "one fits all" group thing.
While security groups are ACL based, they still need some kinda enumartion.
So, at the time people had more and more groups and more and more members
have been in that group and sending group IM´s, the system degraded. If
this would have been limited to communication it would have been discomfort
- but getting the enumeration in groups getting stale, so influence in
collaboration, it was a pain in the neck.
The advantage would be the goal Charles did outline: move on to the next
frontier. You could keep compatibility on one (security) while setting up
a more advanced (maybe XMPP, wich could be a voice basis as well) solution
for the other
(communication).
Besides that - yes, collaboration needs communication. Call me old style -
I still prefer to be able to access files, portals and print over email
@work. I can still pick up the headset. So I would prefer to isolate the
communication from security for availability means, as well.
</pre>
</blockquote>
<pre>i would argue that we first of all need a proper group system, then we can make
use of the group system for various other purposes, such as access control,
modification rights, communication purposes.
DrS/dirk
</pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>