[standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)

nick nick at jabberstudio.org
Sun Sep 22 13:58:35 CDT 2002


Maybe you can help me here. What exactly is the point of a tree like 
system of rooms? That is very very implementation specific. Not exactly 
idea for a protocol...

Pasi Parnanen wrote:

>Thanks for reading my proposals, David. 
>
>
>Minimal change was one of the restrictions we were working with in the
>talks on jabber at jabber.org. We wanted extended functionality with as
>little change to the conference system itself as possible. Mainly
>because we didn't know how much of the conference code that could be
>altered... We planned on using a web page for the tree of places and
>bots to take care of authentication.
>
>We try our best to understand that there has to be compatibility between
>conf 1.0 and 2.0 requests, but hope that it will be so in a upward
>manner, without setting limits on new and badly needed functionality. 
>
>Voice, like it now stands in JEP-45:0.6, is such a new function as well
>as kick and ban. All three would need to have new interactions. But is
>this the only functionality we need to have added? The ability to create
>rooms is present in the v.1, but we also need to restrict that in v.2.
>
>The introduction of a hierarchical system for the rooms would create a
>simple, yet capable system for administering the rights for groups of
>rooms. To allow the administrators to take full advantage of this
>hierarchy the only necessary addition would be to allow (child) rooms
>within the room. The parent rooms would indeed be out of the scope of
>this JEP, which is slightly strange. What is the JEP for that, btw?
>
>The result of being kicked would also be more logical with a
>hierarchical approach. The participant would not be thrown off the
>server but merely yanked out of the room and into the parent room. This
>would increase the "staying-factor", i.e. the participant would stay
>with the same site better. The participant would also meet more people
>because there would be people in the room he or she was "kicked" into. 
>
>Having a hierarchy would also increase the "cross-pollination" of rooms
>and allow similar rooms to link to each other. Both by grouping rooms
>logically and by adding symbolic links between rooms. We think it would
>increase the number of visitors. Even with the same number of
>participants we would seem to have more people in the jabber conference
>(compared to other systems) because the flow of people would be more
>visible. The corridors wouldn't be mute, as we call it. With IRC and
>conference v.1 the corridors are.   
>
>The visitor could even pick a home room to go to, like *nix users have
>home catalogs. A virtual cubicle, perhaps? Or a penthouse?
>
>
>If we implement kick, ban and room creation now without having a
>hierarchy then the chance of having the hierarchy later will die from a
>horrid downwards compatible recursive curse... That functionality will
>for ever be stuck in it-works-so-why-change-it-limbo.
>
>We think jabber conferences deserve better.
>
>
>-- Pasi "BlackDog" Parnanen
>
>
>
>David Sutton:
>  
>
>>I get an idea of what you are trying to achieve, but in some respects
>>I feel its beyond the realms of this jep. One of the core aims is to
>>ensure compatibility with the existing GroupChat v1 code. What you are
>>proposing, although an interesting concept, would be hard to keep that
>>goal with. My attitude has been 'fix what we have now, and then once
>>we're stable, we can create new, advanced conferencing protocols safe
>>in the knowledge that what we have works now' and I still believe that
>>now. 
>>
>>  In the end, it is up to Peter Saint-Andre, but thats my feelings on
>>  the matter :)
>>
>>Regards,
>>
>>  David
>>
>>On Sun, Sep 22, 2002 at 11:44:01AM +0200, Pasi Pärnänen wrote:
>>    
>>
>>>David Sutton (in response to Peter Saint-Andre):
>>>      
>>>
>>>>Ok, regarding roles - does admin imply voice, or should two roles 
>>>>elements be given, one for admin and one for voice? Actually, in the 
>>>>examples, you have voice as a seperate element - should it not be a 
>>>>role?
>>>>        
>>>>
>>>In the talks in the jabber room the method was to compare the collection
>>>of rooms with a folder hierarchy.
>>>
>>>
>>>Thus... 
>>>
>>>Each room (or "place") would have:
>>>owner - admin - participant
>>>access - voice - create
>>>savcavcavc
>>>
>>>...compared to:
>>>user - group - other
>>>read - write - execute
>>>lrwxrwxrwx
>>>
>>>
>>>Example actions:
>>>
>>>kick:
>>>Temporary remove access to place and send to parent place.
>>>
>>>block:
>>>Remove access to place and send to parent place.
>>>
>>>ban: 
>>>Remove access to all conference places and terminate session.
>>>
>>>mute:
>>>Remove voice.
>>>
>>>speak: (a better word must exist)
>>>Remove voice from all participants in the room except one.
>>>(useful for moderated places)
>>>
>>>hush:
>>>Remove voice from all participants.
>>>
>>>promote: 
>>>Make the participant an admin in this place (and in subsequent places).
>>>
>>>degrade: 
>>>Make the admin a participant in this place.
>>>(only available to owner of root place)
>>>
>>>dub:
>>>Make the participant an admin of the entire conference.
>>>(only available to owner of root place)
>>>
>>>deface:
>>>Remove all admin rights for user. (all rooms in conference)
>>>(only available to owner of root place)
>>>
>>>etc...
>>>
>>>
>>>The create right would give the owners, admins and in some places even
>>>the participants the right to create new places, a bit like folders
>>>within folders.
>>>
>>>The browse places could then be used in a manner similar to looking at a
>>>file system tree, maybe even with the number of users in each place
>>>visible.
>>>
>>>
>>>In *nix, everything is a file, and our idea was that in the conference,
>>>everything would be a place. With the idea of having a "tree of rooms"
>>>we could even have quick shortcuts between places within the conference,
>>>if we want to. 
>>>
>>>parent:
>>>pavcav-a--	stpeter gods 	12 	throneroom
>>>
>>>shortcut:
>>>savcav-a--	stpeter gods 		audiences -> ../../throneroom
>>>
>>>place:
>>>-avcav-av-	da_king guards 	 3	oubliette
>>>
>>>
>>>The "tree of places" would be fairly easy to understand for newcomers
>>>too, we think. 
>>>
>>>
>>>-- Pasi "BlackDog" Parnanen
>>>-- If there is blame then cast it upon me and not upon the innocent. 
>>>
>>>
>>>_______________________________________________
>>>Standards-JIG mailing list
>>>Standards-JIG at jabber.org
>>>http://mailman.jabber.org/listinfo/standards-jig
>>>      
>>>
>>-- 
>>David Sutton
>>Email: dsutton at legend.co.uk
>>Jabber: peregrine at legend.net.uk
>>    
>>
>
>
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>  
>




More information about the Standards-JIG mailing list