Re: CCXML Event Handling

Hrvoje,

The idea around the text in the spec was that an interpreter would  
update it's ecmascript objects with the current call state when you  
pulled the event off the queue. This solves a lot of issues with  
dealing with concurrent threads as you can always count on your  
ecmascript state staying the same while in the process of running a  
single <transition/>

     RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800



On May 11, 2005, at 5:14 AM, Hrvoje Nezic wrote:

>
> I have a question regarding CCXML Event Handling (section 9.1
> in the specification):
>
> " During the processing of an event by the EHIA, the state of any
> ECMAScript objects exposed by a platform, such as the Connection
> object, must reflect the state of the CCXML session immediately
> following the occurrence of the event.
>
> For instance, if a 'connection.alerting' event is being processed
> against a connection with ID 1234, then session.connections 
> ['1234'].state
> would have a value of 'ALERTING'. This is true even if the actual  
> connection
> has already been terminated, with a 'connection.disconnected' event  
> queued
> (but not yet processed) against the session. "
>
> I am not sure how this should be interpreted. The above example is  
> clear,
> but it seems that the first sentence would imply that for every  
> event we
> need to make a "snapshot" of all objects managed by the session
> (connections, dialogs and conferences), because they are all
> exposed to the transition handling the event and they all could be
> changed between throwing and handling of the event. However, this
> looks like an overkill.
>
> Or should it be interpreted that this refers only to the objects  
> that are
> properties
> of the corresponding event (connection in the above example)?
>
>
>
>
>

Received on Monday, 16 May 2005 14:57:19 UTC