> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> Lawrence, Scott (BL60:9D30)
> Sent: Saturday, August 29, 2009 11:28 AM
> To: M. Ranganathan
> Cc: sipX developers
> Subject: Re: [sipX-dev] Openfire chat room management 
> assumptions / questions
> 
> On Fri, 2009-08-28 at 19:36 -0400, M. Ranganathan wrote:
> > 
> > 
> > On Fri, Aug 28, 2009 at 4:15 PM, Robert Joly 
> <[email protected]> wrote:
> >         
> >         >
> >         > > I am writing some openfire xmpp chat room management
> >         functions and
> >         > > would like to validate some working assumptions:
> >         > >
> >         >
> >         > >
> >         > > 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 ). 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?
> >         >
> >         > I would leave the xmpp commands out of this for 
> now (unless
> >         > they come for free - I'm looking into that) and stick with
> >         > XML-RPC i/f.
> >         
> >         
> >         They indeed come for free.  The openfire multi-user chat
> >         offers the
> >         following command natively:
> >         
> >         affiliate, ban, clear, clearall, config, configure, debug,
> >         help, invite,
> >         join, kick, me, msg, nick, part, ping, register, role, say,
> >         topic.
> > 
> > 
> > It turns out that you cannot actually manupulate the MUC room state 
> > (i.e. invite new users, kick etc. ) *unless* you are 
> already part of 
> > the conference to start with. In other words, you would 
> have to join 
> > the chat already to invite users. Hence, it makes little 
> sense to have 
> > a web interface for these operations.  You would be part of 
> the chat 
> > anyway - might as well simply issue the command from there 
> or if the 
> > client you are using has the capability, it can send these commands 
> > using xmpp.  An alternative approach would be to use the 
> smack library 
> > to join the conference from sipxconfig and then issue the command.
> > 
> > The conclusion I have is that XML RPC does not seem particularly 
> > useful for chat room management.
> > 
> > 
> > Hence, for now, I am only retaining the list participants 
> > functionality in the XML RPC interface. The other 
> operations should be 
> > done using command line or via an imbedded xmppp client (i.e. smack
> > library) from sipx-config.
> 
> Most XMPP clients have good support for these capabilities; I 
> don't think that we need an alternative.
> 
> Having the membership reflected in an integrated voice/text 
> conference display would be cool.  If I'm looking at the web 
> ui for my voice conference bridge, I should be able to see 
> which people are in which media session.
> 
> 

As part of the Personal Assistant I support voice conference related
IM commands such as 
   - who => who is/was talking
   - list => list participants
   - mute/unmute participant
   - disconnect participant
   - lock/unlock

So having chat room IM commands provides consistency.

> 
> _______________________________________________
> 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/
> 
_______________________________________________
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/

Reply via email to