Re: Updated IRP for uSCXML

Stefan,
   We do need implementations to pass test513 (or something like it) to 
standardize the BasicHTTPEventI/O processor.  However there must be an 
open-source tool kit that will do simple HTTP testing such as letting 
you send a request to a URL and then check the response code.  If we had 
something like that, no one would need to add this extension to their 
implementation.  All we need to do is to send a well-formed SCXML event 
to the interpreter and check that it returns a 200 response code.  But 
if we can't find something like that, we will need people to implement 
this extension.

- Jim
On 6/25/2014 9:57 AM, Stefan Radomski wrote:
> On Jun 25, 2014, at 15:42, Jim Barnett <1jhbarnett@gmail.com> wrote:
>
>> Stefan,
>>   On test513, do you have some other  way to test that the SCXML interpreter sends back an HTTP response code after receiving a message?   We're trying to test the following assertion:
>>
>> "After it adds the received message to the appropriate event queue, the SCXML Processor MUST then indicate the result to the external component via a success response code 2XX."
>>
>> The extension used in test513 is one way to do that, but if there are other or better ones, we can use them instead (or in addition).
>>
> I am afraid not. If it is imperative to get SCXML standardized, I can implement it though.
>    Stefan
>
>> - Jim
>> On 6/25/2014 4:48 AM, Stefan Radomski wrote:
>>> Hey there,
>>>
>>> attached is the updated IRP for uSCXML, we now pass all tests but:
>>>
>>> - the one where the XPath DM is hardcoded
>>> - test513 which tests for an unimplemented http extension
>>> - test520 "this is some content” is unescaped in search string
>>> - test531 <content>_scxmleventname=test</content> is invalid to set the event name in our implementation
>>> - test579 with the recent addition of history transitions
>>>
>>>
>>>
>> -- 
>> Jim Barnett
>> Genesys
>>

-- 
Jim Barnett
Genesys

Received on Wednesday, 25 June 2014 14:22:02 UTC