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

Re: [reSIProcate] Sharing DUM State


see inline.

On 3/1/07, Nilay Tripathi <nilay.linux@xxxxxxxxx> wrote:
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.

The dum state machine is incredibly complex. I don't agree that we
should expose this to users of dum. By using methods like isConnected
and isEarly we make the code that uses these methods resilient to
changes in the internal state machine - which are still quite likely
to occur as we add in support for such things as 100rel (PRACK).

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
>
>
>
>
>
>


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