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

Pasi Pärnänen pasi at parnanen.net
Wed Sep 25 09:38:16 CDT 2002


Hello again.


Destruction of a room is easy to handle. Kick everyone (including
myself) and remove it. 

Without the persistance set the easy way to remove a room would be to
kick everyone else and walk out.

But how do we interact with a room that doesn't exist?

Logically the creation would be handled by the conference. The room
itself doesn't know if it is allowed to be created. Only the conference
would know that. 


The system you suggest, using only...
room at service.domain.tld/participant
would remove the possibility of having rooms with identical names in
different parts of a hierarchy. A file system with that kind of
limitation would be pretty useless to implement and harder to use. 

We think that even...
oubliette.dungeon.darkcastle.devilmountain at roleplay.jabber.org/BlackDog
would be easy for both the user and the programs to handle. 

And with a shortcut in the hierarchy (that still is outside this jep)
the conference could indeed allow you to have... 
oubliette at roleplay.jabber.org/Blackdog 
available for chatting. 


-- Pasi Pärnänen (BlackDog)



Richard Dobson:
> BlackDog:
> > The creation and destruction of rooms are now specified as being in the
> > scope of JEP-0045, but wouldn't it be more logical to define those
> > actions in the new conference JEP?
> >
> > And how do we address a participant if he or she is in a room at the
> > second level of a hierarchy? Would it be in the form of:
> >
> > level1.level0 at service.domain.tld/participant ?
> 
> Creating and destructing rooms is not outside this JEP since it is dealing
> with interactions with the rooms, it just doesnt cover how rooms relate to
> each other since that has nothing to do with interaction with a particular
> room.
> 
> Also isnt it better not to use your:
> 
> level1.level0 at service.domain.tld/participant
> 
> And just use as intended:
> 
> room at service.domain.tld/participant
> 
> Even with your hierarchy you do not need to have the whole hierarchy as part
> of the address, what if it ends up in lots of levels:
> 
> level9.level8.level7.level6.level5.level4.level3.level2.level1.level0 at servic
> e.domain.tld
> 
> That is just getting silly, when all it needs to be is:
> 
> room at service.domin.ltd
> 
> How the rooms relate to each other has nothing to do with the room address
> itself, and in my opinion should not do, and there is no need for it if you
> want to do it properly. Why do you want to do it that way anyway?
> 
> Also I still dont see the need for these sub rooms, I can see the need to
> group rooms by subject but isnt it better to have a folder like grouping
> mechanism like already exists in browse (tipic.com has a folder structured
> browse), rather than sub rooms which in my opinion complicate things for
> users trying to understand whats going on.





More information about the Standards-JIG mailing list