Re: Updated IRP for uSCXML

On Jun 25, 2014, at 17:20, Jim Barnett <1jhbarnett@gmail.com> wrote:

> If that works, we can use it as a manual test.   Should I just replace test513.txml with test513.txt which describes how to run the test.  Will wget show the return code from the SCXML implementation?  The description of the test should be quite precise.

Yes, return code will be shown:

$ wget \
--post-data='key1=value1&key2=value2’ \
--header '_scxmleventname: test’ \
http://epikur.local:8090/925c760f-2093-4054-a24c-d972d75f0dcd/basichttp

--2014-06-25 17:54:49--  http://epikur.local:8090/925c760f-2093-4054-a24c-d972d75f0dcd/basichttp
Resolving epikur.local (epikur.local)... 10.211.55.2, 10.37.129.2, 10.0.1.54, ...
Connecting to epikur.local (epikur.local)|10.211.55.2|:8090... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Saving to: ‘basichttp’

    [ <=>                                                                           ] 0           --.-K/s   in 0s      

2014-06-25 17:54:49 (0.00 B/s) - ‘basichttp’ saved [0/0]

Regard
Stefan

> 
> - Jim
> On 6/25/2014 11:17 AM, Stefan Radomski wrote:
>> wget will do that:
>> 
>> # open netcat to listen on a tcp port / this ought to be the scxml interpreter ultimately
>> term1$ nc -l 8090
>> 
>> # send an application/x-www-form-urlencoded post request
>> term2$ wget --post-data='key1=value1&key2=value2' --header '_scxmleventname: test’ localhost:8090
>> 
>> # see its HTTP representation in netcat
>> term1$ nc -l 8090
>> POST / HTTP/1.1
>> User-Agent: Wget/1.15 (darwin13.2.0)
>> Accept: */*
>> Host: localhost:8090
>> Connection: Keep-Alive
>> Content-Type: application/x-www-form-urlencoded
>> Content-Length: 23
>> _scxmleventname: test
>> 
>> key1=value1&key2=value2
>> 
>> 
>> Regards
>> Stefan
>> 
>> On Jun 25, 2014, at 16:21, Jim Barnett <1jhbarnett@gmail.com> wrote:
>> 
>>> 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
> 
> -- 
> Jim Barnett
> Genesys

Received on Wednesday, 25 June 2014 15:59:27 UTC