On 4/3/06, Fasihullah Askiri <[EMAIL PROTECTED]> wrote: > <snip> > * If a "line" from your snippet earlier is a "call", then the correct > way to handle the events is per a SessionManager. Whether we're using > HTTP and the servlet API (see usecases on the web site) or some > protocol of choice over a SIP-based communication channel, bookkeeping > for the events and sessions / calls has to be done at the "container" > level, rather than by Commons SCXML. > </snip> > Could not really get this. Can you explain? By the way, I am using a SIP > stack to do the dialog management. > <snip/>
That had to do with the comment about "broadcasting" an event vs. directing it to the correct state machine. My SIP is rusty, but in any event, the broadcasting should be unnecessary, since AFAIK the SIP communication channel is established per UA. With regards to the SCXML usecases on the website I refered to (these are within the realm of servlet container and stateless HTTP - cross component dialog management using RDCs, and cross-page navigation using Shale dialogs) where the following happens: * Some "application event" (received over HTTP) causes a state machine to be instantied * The state machine gets associated with the current HttpSession * Numerous state machines may be instantiated (once per session/"call") * Subsequent application events are directed at the same state machine by identifying the session (using container provided mechanisms) -Rahul > +Fasih > <snap/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
