Re: [reSIProcate] Wish to merge some of the changes we made from TelTel client branch
Hi Nash,
Most of this looks good to me. I like the Command stuff you started -
it should help users of dum to be thread safe.
My only concerns are:
1. We need to comment in all header files - what the differences are
between the xxxx and xxxxCommand methods are. Ie. one is asynchronous
and thread safe.
2. Can you explain why you need the ability to pass a mutux to the
DialogUsageManager process functions?
3. Looks like the ExternalMessage has some strange Win32 isms (ie. use
of Win32ExportDum.hxx), that I'm not sure are appropriate for a general
commit.
4. I'm not a big fan of the onAckReceived callback you added - since it
will end up getting called for session timer refreshes - if this is
something that is required it should be designed a bit better. Also, it
conflicts in naming with already existing onConnectedConfirmed callback.
Anyone else?
Scott
> -----Original Message-----
> From: Nash Tsai [mailto:nash.teltel@xxxxxxxxx]
> Sent: Friday, March 30, 2007 2:31 AM
> To: Scott Godin
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Wish to merge some of the changes we made from TelTel client
> branch
>
> Hi Scott,
>
> Included attachment contains changes that is in TelTel client branch,
> and I would like to merge into the main trunk, the reason being we
> would like to switch back to main trunk.
>
> Let me brief the changes, as we used blocking FIFO DUM in another
> thread space other than Main Thread, so DUM doesn't not keep polling
> the messsages and in order to make sure DUM access is within the same
> thread I provided async function access, have look @ class
> InviteSession, for example, all synchronized access methods has
> provided another version of allowing async access, ie,
> provideOfferCommand, provideAnswerCommand, infoCommand,
> acceptNITCommand, etc. Add these changes will not affecting exiting
DUM
> developers.
>
> Another change is InviteSessionHandler.hxx, for the onAnswer handler I
> added an extra param - AnswerReason, to tell the onAnswer is triggered
> at first invite, re-invite, or ack, this will affect existing DUM
> developers, and I hope I am allow to commit these changes.
>
> Regards,
> Nash Tsai