[standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)
vapor at 66oc.org
Wed Sep 25 13:56:24 UTC 2002
The idea behind a heirarchy would be to bring a level of functionality to
the conference server that I have not found in any text conferencing to
date. But we do see this kind of heirarchy in both Domain names and
similarly in the usenet.
The purpose goes beyond grouping similar topics into a single folder, but
grouping them into a scalable top down structure.
Examples of this kind of use. I am a member of a gaming group called 66OC.
I have conference.66oc.org as my public conference server, but I share this
server with many other clan to use, I also use this server with a
developement group I work with and then my friends outside of this. I could
have a bunch of different rooms named "66OC general", "66OC AvP2", "66OC
1942", "Jabber Development", and then a few rooms based on other topics. If
heirarchy was implemented though, I could have
66OC at conference.66oc.org/whatever and with me as the administrator of that
room and all lower level rooms. All lower level rooms would be organized as
AvP2.66OC at conference..... and 1942.66OC at conference..... and then
teamdiscussions.66oc at conference.org.
Another example would be using the conference server in a corporate
environment. You would have different organizations within a corporation.
For example, IT Operations who all report to the CIO would be under the top
folder of itops at conference.company.com. then you may have
development.itops at conference.company.com,
support.itops at conference.company.com and
engineering.itops at conference.company.com. From there you can add in
desktop.support.itops at conference.company.com and
helpdesk.support.itops at conference.company.com and so on. This would allow
for a heirarchy to administer by too. There may be a better way to do this,
this is just what we have come up with so far. It could also allow for
rooms to be linked together if you wanted to build more of a community like
If somebody has a better idea for how this could be implemented, please let
us know, we just think there would be a demand for this sort of heirarchy.
As companies begin to embrace IM more and more, they will probably start
seeing an advantage to having a heirarchy system in place that would allow
for teams to gather in to to communicate with. And would allow for people
to move up and down the heirarchy to communicate about things on a broader,
or more defined level. The heirarchy doesnt have to be implemented at all,
but if the functionality were in the conference server, it would bring
another level of appeal to jabber that doesnt exist for other IM services.
Jared Cluff (Vapor)
----- Original Message -----
>From: "Richard Dobson" <richard at dobson-i.net>
To: <standards-jig at jabber.org>
Sent: Wednesday, September 25, 2002 6:48 AM
Subject: Re: [standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)
> > But before we can start our work...
> > 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
> 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
> of the address, what if it ends up in lots of levels:
level9.level8.level7.level6.level5.level4.level3.level2.level1.level0 at servic
> 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
> 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.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards