Re: [reSIProcate] Sharing DUM State

["Nilay Tripathi" <nilay.linux@xxxxxxxxx>]

Hi All,

I am not very sure what type of backward compatibility issue(s) with DUM may come with this kind of change as we are not allowing any change to state outside DUM. Certainly, the atomicity of the operation must be there for a thread-safe scenario.

Moreover, I find it better that we provide the state instead of writing these small functions like isConnected, isEarly ... etc. as sharing state info makes it very scalable also.

Thanks & Regards,
Nilay

On 3/1/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

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@xxxxxxxxxxxxxxxxxxxx [mailto: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of qiu michael
Sent: Thursday, March 01, 2007 8:35 AM
To: Nilay Tripathi
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx>:

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@xxxxxxxxx> 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@xxxxxxxxx>:

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@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel