Mircea Carasel wrote: > Kevin Thorley wrote: >> On Thu, 16 Jul 2009 15:22:32 -0400, Robert Joly wrote: >> >> >>> Folks, >>> I noticed that XX-5547 calls for the addition of many information >>> elements related to a user. One of those elements is the IM Handle >>> which is defined as the IM handle to be used on the sipXecs system. As >>> part of our Openfire integration work, we have added an IM ID field to >>> the 'Add User' page. Upon creating a new SIP user with a non-blank IM >>> ID, sipXconfig executes the appropriate XML-RPC requests to have the >>> corresponding IM account created in Openfire. My question is about the >>> relationship between the IM ID field in the 'add user' page and the 'IM >>> handle' in the user portal requested in XX-5547. Are these fields one >>> and the same? Will sipXconfig request openfire account creation upon >>> initialization/modification of the 'IM handle' from the user portal? >>> >>> >> >> My apologies if this is a slight hijacking, as I probably won't answer >> the actual question... >> >> The current way that sipXconfig handles the openfire configuration is >> probably going to need to be modified. Ranga and I spoke about this >> yesterday and are planning a talk in the morning on #sipx. I notified >> the sipXconfig crew this morning so those who are interested can be >> there. The short story is that any configuration that is done via >> sipXconfig should be stored in the sipXconfig database. Therefore, any >> new fields that are added to support openfire, such as the user's IM >> handle, need to be modeled as part of a sipXconfig user and stored >> locally. Any replication to the openfire server should then go through >> the regular channels, or a new channel, such as XML-RPC direct to the >> openfire process, but still through the standard sipXconfig replication >> mechanism. >> >> So, more to the point, if these handles are one and the same (it sounds >> like they are), there should only be one master copy of that data, living >> in sipXconfig. The openfire server will be updated with that new/changed >> data when replication takes place. >> > The IM id field that I put for openfire is saved in users table in > sipXconfig database. > Actually I added a new column to users table that holds the IM id. > Also there is XML-RPC method that I call in order to save it in openfire > server side. > The only problem is that now, with new design of user information there > is an im ID field > that gets saved in a new table: address_book_entry - that is in relation > of 1-1 with users table. > When Damian will make the merge between XMPP branch and the main branch, > probably he will > not merge IM id added in XMPP branch (will keep only the XML-RPC calls) > and will use the new approach that is already commited > in main
That's exactly what I plan to do. No need to have 2 places for the same data item. Although we can obviously to display/edit it in more than one place. I'll have a better view once I actually see the new openfire screen. D. 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/
