<div>Given that recent clients have a web browser built in, could we make use if it for managing group attributes that may deviate from the SL model?</div>
<div><br><br> </div>
<div class="gmail_quote">On Wed, Jul 2, 2008 at 11:15 PM, Dr Scofield <<a href="mailto:DrScofield@xyzzyxyzzy.net">DrScofield@xyzzyxyzzy.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div bgcolor="#ffffff" text="#000000">
<div class="Ih2E3d">Melanie wrote: 
<blockquote type="cite"><pre>Hi,

Dahlia Trimble wrote:
  </pre>
<blockquote type="cite"><pre>Perhaps there is some basic plumbing or initial functionality
that can be added, but given the current problems with the LL implementation
and some of the objectives and efforts of groups like the AWG, I would
suggest we try to get more of a big picture perspective of what groups could
be before implementing anything that requires a lot of work and may be
difficult to change once added. On the other hand, could a simple interim
solution be added which can be easily (for end users) replaced?
    </pre></blockquote><pre>I believe that we will not want to copy SL's solution 1:1. We will 
want to consider things like cross-grid use, and the 25 group limit.
However, the standard is the SL client, which means we need to 
create a group structure for which a valid representation can be 
created and managed using the client.
I think we all agree that we should not _limit_ groups to what the 
client can do, but we should find a representation that reduces the 
interface to the point where, within that scope, the client can deal 
with it.
  </pre></blockquote></div>+1 
<div>
<div></div>
<div class="Wj3C7c"><br>
<blockquote type="cite"><pre>The main thing would be to implement the plumbing, since that job 
touches many parts of the code. However, that is fairly 
straightforward, although lots of work.
Once it's plumbed in, different backends and interfaces can be 
created, to levarage the features of other clients, or a mixed 
in-client and web administration.
Permissions-only groups can quite possibly be handled much 
differently, but i don't think that 25 is all she wrote.
I haven't tried it, but i see nothing in the protocol that prevents 
the group list from being longer, even much longer. The protocol 
already supports breaking it into several packets, which bit me when 
i made my first inviter bot. So it may be that the client won't mind 
being sent 50 or 75 groups...

  </pre>
<blockquote type="cite"><pre>I like the idea that permission groups and chat/notice groups could be
seperate implementations. I've always had trouble juggling groups to stay
within the 25 group limit and several times I've avoided situations that
requiired joining a group for permissions if I needed to sacrifice a more
social 
    </pre></blockquote><pre>Yes, +1. That should be avoided. Maybe a web interface that handles 
group creation, as, I believe, the client does grey out the "New 
group" button when you have 25 in the list.

But, maybe the client will be patched by some kind soul...

But, +1 on trying to improve, certainly.

Melanie

_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>

  </pre></blockquote><br><br></div></div>
<div class="Ih2E3d"><pre cols="80">-- 
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
SL: dr scofield ---- <a href="mailto:drscofield@xyzzyxyzzy.net" target="_blank">drscofield@xyzzyxyzzy.net</a> ---- <a href="http://xyzzyxyzzy.net/" target="_blank">http://xyzzyxyzzy.net/</a>
RL: <a href="mailto:hud@zurich.ibm.com" target="_blank">hud@zurich.ibm.com</a> - +41 44 724 8573 - <a href="http://www.zurich.ibm.com/~hud/" target="_blank">http://www.zurich.ibm.com/~hud/</a>
</pre></div></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>