[reSIProcate] Sharing DUM State

[qiu michael]

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/035cef6a/attachment-0001.htm>