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