[reSIProcate] Sharing DUM State

[Scott Godin]

We have tossed this idea around in the past, but then decided not to
expose the state directly to the application - since we would then need
to be very careful about backwards compatibility of DUM when adding or
modifying the current state machine.  The current scheme is to add
Boolean functions that return state information that the application
would care about:  for example:  isConnected, isTerminated, isEarly,
isAccepted. 

 

Scott

 

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of qiu
michael
Sent: Thursday, March 01, 2007 8:35 AM
To: Nilay Tripathi
Cc: resiprocate-devel at list.sipfoundry.org;
resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] Sharing DUM State

 

If my project, I did it by myself. And I think that should be more
flexible, and make the lib simpler. :)

2007/3/1, Nilay Tripathi < nilay.linux at gmail.com>:

Hi,

If I am getting it correct then I feel atomicity is going to be more
relevant in a threaded environment, and for that purpose, yes it should
be an atomic operation. 

Let me know your thoughts on this !!

Regards,
Nilay

 

On 3/1/07, qiu michael < antelope.qiu at gmail.com
<mailto:antelope.qiu at gmail.com> > wrote:

I need it too. But I think it's a little bit problem. We have to make
this handle be atomic.
Do you think so?

2007/3/1, Nilay Tripathi < nilay.linux at gmail.com
<mailto:nilay.linux at gmail.com> >:

Hi,

DUM maintains state for each dialog/session. It is defined in class
InviteSession. 

What I am curious about is that, is there going to be any problem if we
share this 
state through the handles? Which precisely means writing a public 'get'
function and 
pulling out the 'state' enum into 'public'.

I feel this would be a good to have thing, for lets say that I want to
integrate this to a 
minimalistic call-fsm. This would save from changing into the provided
call-fsm and 
also need not maintain states separately. Of-course, state transition
would not be 
allowed but re-usability of DUM states can make life simpler :)

Thanks in advance!!

Regards,
Nilay 

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org 
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070301/46aa33e5/attachment-0001.htm>