RE: CCXML Event Handling

RJ,

For example, I take your reply to mean that if the CCXML platform queues
a connection.progressing event and then queues connection.connected
event before the progressing event is processed that when the
progressing event is processed that the connection object reflects that
the connection is in connected state (i.e. in the state property of the
connection object).

                    Event Queue
                    -----------
 add connection.progressing -->                          state =
progressing
 add connection.connected   -->                          state =
connected
                    --> process connection.progressing   state =
connected

Vince

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of RJ Auburn
Sent: Monday, May 16, 2005 7:51 AM
To: Hrvoje Nezic
Cc: www-voice@w3.org
Subject: 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 Tuesday, 17 May 2005 02:18:45 UTC