Re: [reSIProcate-users] why is asyncProvideContacts() called twice for a registration
It's been quite a while since I poked around in the server registration
code, and I don't think the async logic was in there the last time I
did, but I suspect that the design you've described is to allow the
external database to contain some level of business logic. Or, at the
very least, if there is some kind of error updating the database,
ensuring that the list of contacts sent back to the UAC matches what is
actually in the database.
/a
On 2/23/10 15:54, Feb 23, Michael Trank wrote:
For a registration using an external infosystem as a place to
authenticate requests and store registered contacts, I see that the
ServerRegistration class has a state machine that requires that the
list of current contacts for a subscriber be provided *twice* by
calling asyncProvideContacts().
I understand the first time, when the current list from the back-end
system is brought into ServerRegistration, and ServerRegistraion goes
through this provided list, adds or updates the contact for the
request that has just been received, and then pushes this back to the
back-end system with asyncUpdateContacts() from my implementation of
the ServerRegistrationHandler.
But then ServerRegistration gets put into
asyncStateAcceptedWaitingForFinalContactList state.
What is the need to wait again for another list from the back-end? Is
it expected that the back-end will or might do something besides
update it's own list?
Does this have something to do with the "transaction log"?
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/