[Opensim-users] Groups Implementation Discussion (Ai Austin)

[Diva Canto]

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.

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.

Charles Krinke wrote:
> I think we have two "groups" discussions and perceptions going on.
>
> 1. "Group Communication" - This involves text based chat windows with 
> messages forwarded to all the members of a group.
>
> 2. "Group Permissions" - This involves how a member of a group may 
> terraform region parcels and edit/transfer objects owned by a group.
>
> 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.
>
> But, I respect that there is a second focus.
>
> 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.
>
> Charles
>
> ------------------------------------------------------------------------
> *From:* Diva Canto <diva at metaverseink.com>
> *To:* opensim-users at lists.berlios.de
> *Sent:* Monday, April 6, 2009 8:50:07 AM
> *Subject:* Re: [Opensim-users] Groups Implementation Discussion (Ai 
> Austin)
>
> 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.
>
> Dr Scofield wrote:
>> Ralf Haifisch wrote:
>>   
>>> *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.
>>>     
>> 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
>>
>>   
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20090406/ecb9445e/attachment.html>