Thank you for your quick response. Some more clarifications below:
On Fri, Aug 28, 2009 at 2:30 PM, Damian Krzeminski <[email protected]>wrote:
> M. Ranganathan wrote:
> > I am writing some openfire xmpp chat room management functions and would
> > like to validate some working assumptions:
> >
> > 1. Each user can create chat rooms from his user portal. This will be
> > written into the xmpp-account-info.xml file and the plugin will
> > instantiate the chat rooms by scanning that file. The subdomain for the
> > chat room will be fixed and set to the user name.
>
> If chatrooms are always associated with existing voice conferences (in a
> way Dimdim conference is associated with voice conference now) that should
> be OK.
>
> To be more precise: there won't be any creating new chatrooms from user
> portal (just as today there isn't any creating new conferences from user
> portal). Admin creates conferences (and by extension chatrooms) for end
> user manually or automatically (if they are members of groups that have
> automatic creation of conferences enabled).
>
OK with this model for first release. I think creating a chat room is a
lighter weight operation than creating a voice conference (needs less
resources) so I allow the user have control over this but for this release
we can just allow the admin to create chat rooms.
> >
> > 2. Each chat room will have an associated conference number. This can be
> > an extension assigned to a voice conference. The owner can direct all
> > members to join a conference call using a command in the chat window. I
> > don't think we will need xml rpc support for this ( please correct this
> > assumption if wrong ).
>
> How would openfire know who is a "member" ("participant") in this context?
> sipXconfig does not have any notion of pre-configured conferences at the
> moment. The owner can invite anyone at any point, but there is no "all"
> here.
>
The chat room is created during the initialization of openfire and
subsequently any chat rooms that do not appear in xmpp-account-info.xml are
deleted. This file is continually scanned and the chat rooms are updated.
The file does not contain any chat room member information. This is stored
as part of the server state of openfire ( can be persisted ).
The chat room definition (xml) has "room-owner" as one of its elements (see
sipXopenfire/schema). When the chat room is created, the owner and other
attributes are assigned to it.
In answer to your question : there is a packet interceptor that runs in
openfire. You can write code that examines the incoming packet ( I mean xmpp
packet in this context ) and execute an appropriate command. You can test
the source of the packet ( i.e. who is sending the packet ) to see if it is
from the MUC room owner.
The reason for asking this question about how to initiate this action is -
do we want for sipxconfig to do an xml rpc command to initiate the "invite
to join chat" from the plugin or do we want to just parse the incoming
packet to determine whether or not to do this action. The advantage with the
parsing approach is one does not need to be logged into the user portal. One
would of course need to know the special command syntax.
I am also providing a method to list all partiicpants as this is not part of
the state that sipxconfig will manage.
All this management function via sipxconfig of course means more work for
sipxconfig.
Note that having special commands is not mutually exclusive with sipxconfig
mechanisms.
> >
> > 3. The user is the administrator as well as the owner of the chat room.
> > He can invite new members and kick existing members ( same way as we do
> > for conference ).
>
> Makes sense to me. When you disconnect the participant from voice
> conference he or she should be removed from chat room. Same with invites.
> That said: sipXconfig will not be trying to enforce the chatroom guest list
> based on current participant guest list: since it does not monitor all the
> conferences all the time.
>
> > Do we want to make this an interceptor command (i.e.
> > in line xmpp command) or an xml rpc command that is issued from the
> > user portal?
> >
>
> What's an "interceptor" command?
>
XMPP Packet interceptor mechanism ( see above ) . I agree kicking
participants is not particularly important in a business setting although
inviting participants probably is.
Having said all this, Robert brought up a good point:
We might sidestep multiuser chat room management all together. You can
always invite participants to a conference out of band use email or
soemthing -- although using XMPP to do this means you don't have to supply
the invited user with a password and the experience would be smoother.
Regards
Ranga
D.
>
>
>
> _______________________________________________
> sipx-dev mailing list [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
> sipXecs IP PBX -- http://www.sipfoundry.org/
>
--
M. Ranganathan
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
