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
|