I user could update his/her vCard info via his/her IM client. Would then OpenFire update the same database element?
Peter -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Krzeminski, Damian (BL60:9D30) Sent: Monday, July 20, 2009 12:37 PM To: [email protected] Subject: Re: [sipX-dev] Query about XX-5547 - Extend the user and directoryinformation 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/ _______________________________________________ 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/
