On Thu, Aug 27, 2009 at 8:40 AM, Robert Joly <[email protected]> wrote:
> > > > > > On Wed, Aug 26, 2009 at 3:40 PM, M. Ranganathan > > <[email protected]> wrote: > > > > > > > > > > On Wed, Aug 26, 2009 at 3:26 PM, Scott Lawrence > > <[email protected]> wrote: > > > > > > On Wed, 2009-08-26 at 15:09 -0400, M. Ranganathan wrote: > > > Hello, > > > > > > I am wondering if it is worth the trouble to > > implement persistent chat > > > rooms ( i.e. chat rooms where the participant > > list is persisted over > > > restarts ). It would take some sipxconfig > > work to support this feature > > > ( for example we would need an xml rpc > > interaction to delete such > > > rooms ). > > > > > > Restarts of what? > > > > > > > > Restarts of openfire. > > > > > > > > Can you describe the end-user visible behavior > > difference if it is > > implemented vs if it is not? > > > > > > > > > > > > Persistent chat rooms: The membership state remains > > unchanged even when the members are not actually present. The > > visible difference is for the openfire user. > > > > > > > > Actually slightly mis-stated above. > > > > The membership is decided apriori. You can mark the room > > "members-only" -- which prohibits all except the > > pre-defined members from joining the group chat. > > > > This could be viewed as useful. > > > > Ok, now I'm with you. Maintaining the list of users that are allowed to > enter given room sounds like something useful nut I fail to see how > supporting such a feature implies that we need XML-RPC methods to add > and delete chat rooms. Why can't this be driven from the sipxopenfire > xml configuraion file? > Do we need xml RPC methods then that prune the membership of the chat room while the chat is in progress? To clarify -- if you go to the chat room page in the openfire server, you are able to list participants and kick participants. ( The persistant flag would indicate that this participant list is persisted by openfire. ) So the question is, would we need something analogous in sipxconfig to interact with the openfire server? Note that this is something that can change dynamically as the chat is in progress but it is still persistant so I dont think it makes sense for sipxconfig to store it. It is not configuration state - it is server state. More comments? > > > > > > > > > > > If we want to support this behavior we would need to be > > able to explicitly delete chat rooms or we would need to > > maintain a participant list in sipx so that the > > initialization code knows to delete and re-create the chat > > room. In other words we will need to keep an xml rpc method > > for this purpose. > > > > I do not personally think that this feature would be > > very useful to support. > > > > > > > > > > > > > > -- > > M. Ranganathan > > > > > > > > > > > > > > -- > > M. Ranganathan > > > > > > > -- 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/
