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

Richard Dobson richard at dobson-i.net
Wed Sep 25 15:30:35 UTC 2002

> 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.

Well no thats not the easy way, instead of just kicking everyone out just
delete the room as shown in the spec and then the room does all the work for

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

Because when someone tries to it is automatically created if it does not
currently exist, so if it existed or not when the person tried to interact
with it it will be like it did.

> 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.

But the way you address the packets you are interacting with the room and
never the conference itself in the spec, you always send packets to
room at server.com so you are interacting with the room not the conferencing

> 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.

That is still messy IMHO, also remember there is a byte limit to jid's so
the node section will not be able to expand past 256 bytes so your system
will break if users create a deep or long named heirarchy. So I would
recommend not putting the whole heirarchy into the jid, and all you need is
to make sure that each room address is unique, if there is one with a
particular name already make it suggest a name that will work, (e.g. when
you sign up for aol screennames or hotmail addresses). The relationships
between rooms do not need to be from the jid for your system to work, the
jid's are irrelivant during the process of browsing.

> 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.

Then why not have that in the first place, you need to do it one way or the
other, as "shortcuts" as you put them may not work correctly with clients,
as having a room with two different address will appear to the client to be
two separate rooms.


More information about the Standards mailing list