[reSIProcate] Sharing DUM State

[Nilay Tripathi]

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 at icescape.com> 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 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> 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>:
>
> 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/0eee6246/attachment-0001.htm>