< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

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