Re: CCXML Event Handling

Vince,

No. The connection object would be updated when you take the event  
out of the queue not when you put it into the queue.

     RJ

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



On May 16, 2005, at 11:00 AM, Vince Busam wrote:

> 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 Monday, 16 May 2005 18:05:22 UTC