[JDEV] groupchat <presence/> behaviour??

[Heiner Wolf]

> From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> 
> If this was only going to apply to groupchat, I could see why multiple
> roles might not make sense. However, we have a number of areas which
> this jep can/should impact. Most personally to me is the 
> IRC-Transport.
> The role system would fit with the basic irc model as well, so I can
> utilise it for both.

I know you would say this and I understand your argument. 

> The current concept is that each role level has the abilities of the
> levels below it plus its own abilities. 
> 
> This is my present view on how things may develop in the future.
> 
> * There are two types of attribute - fixed and floating.
> - Fixed attributes are the ones locked to a role, i.e. the ability to
>   add an admin is a fixed attribute to the owner role
> - Floating attibutes are the ones which you may wish to grant 
> to someone
>   of any level, such as invisibility.
> 
> You end up with an easily understandable heirarchy, yet also 
> having the
> flexibility to extend. Does that make any sense?

Actually, :-) no.
I do not like the two structures, what you call fixed and floating. I am
hoping for a single thing that is flexible enough to cover the features
currently ssen as hierarchical rights and more. 

> >
> > Example: a user is admin of another channel and visitor. So 
> he has an
> > icon which shows him as important (because he is admin 
> somwhere else)
> > but still can not say anything, because he is only a listener here.
> >
> Well, surely in this case, you'd prefer multiple icons, even if they
> were similar, so you could tell the difference? You're going 
> to have to
> send a presence packet to each room individually anyway. 

Yes of course I send presence packets to every room. I send my status
and the conf component adds the roles. New partcipants get the full
picture. But that works, is fine, and should just continue to work. No
problems here fromn my side. 

> > There might be more user features/behaviours which you want 
> to control
> > by attributes/roles than what the you can do with the fixed 
> hierarchy of
> > roles. Of course you can control things like visibiliy 
> differently, but
> > since the attributes/roles are there, why not use the 
> mechanism for more
> > than floor control. 
> >
> Mainly because a fixed structure is easier for a user to understand.
> Saying that xyz is an admin means more to a user as they know that an
> admin can do certain things. Saying xyz can do a, b and c is more
> confusing, as there becomes little to differenciate one user from
> another. The idea I talk about above gives a tight core, yet still
> having flexability.

Well, you could turn arguments around and call the attribute oriented
approcah simpler than hierarchical roles. Only ICQ channel ops will  be
used to a fixed structure and levels of access rights. Users won't
notice, because you can configure the attributes to simulate the
hierarchical roles. So owners can be created with admin flag
automatically, but they do not have to. They don't have to if this is
not desired. That is the point. 

Attributes are more flexible. They emulate the hierarchical model, if
required, can do more like "invisibility" or "VIP" which might apply to
all roles. Using the floating attributs from the start eliminates the
need to add a new structure later. 

>From the coders point of view ther is no difference in line count
either. I find it clearer to write:
  if CommandIsAdminCommand && UserIsAdmin then DoIt
than:
  if CommandIsAdminCommand && UserRole >= Admin the DoIt

Anyway, this is not the point. I just argue about flexibility. 

But still, I see that it makes your ICQ transport work more challenging
:-)

> How do you perceive the role of 'moderating' I think we need a firm
> definition here before any discussion should go ahead, 
> otherwise we run
> the risk of talking about different aspects of the same concept.

Being not a native english speaker, am not the expert termninology.
Probably you are right.
I see:

Owner: Creates/configures a room initially, i.e. creates admins
Admin: Administrate the room, create subject, create 
    moderators, creates time slots for special events, sets 
    various flags and operation parameters before and during 
    a session.
Moderator: Moderates in the mailing list sense, i.e. kicks 
    participants off the list, filters lines, if that is the 
    room mode. Does floor control, gives and takes the floor, 
    if that is the mode. Types on behalf of a VIP for a 
    special event, where the mod might even be invisible. 
Participant: We the people. Depending on the room mode they 
    might just talk or have to request the right to talk, 
    or talk, but all lines go to the moderator, who selects 
    input for the public. 
... these were the ones in question.

These are really examples of features we needed, implemented, and
operated in real scenarios.

--
Dr. Klaus H. Wolf
bluehands GmbH & Co.mmunication KG
http://www.bluehands.de/people/hw
+49 (0721) 16108 75