W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

Re: External communication with SCXML

From: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>
Date: Thu, 14 Feb 2013 13:18:47 +0000
To: David Junger <tffy@free.fr>
CC: "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <6A775895400B8040A331C2963964820C1953D28F@exchange01.tk.informatik.tu-darmstadt.de>
> At the moment, the access URI for SCXML sessions in my implementation is http://hostname:firstFreePortAbove8080/interpreterNameWithEventualDigitsPrependedOrUUID/. As I see it, we have a couple of options:
> 
> 1. Even respondable requests get passed into the interpreter as per [1] (request method or _scxmlEventName header value as the eventname) and we send a simple, "200 OK" if we reach a stable configuration without passing a respond. This would still behave as described in the draft, but we could not wait for intermediate events as we will close the request before waiting for more external events.
> 
> 1.1 Introduce a <postpone request="_event.origin"> to inhibit the immediate response on the next stable configuration so we could answer later, but that seems somewhat counter-intuitive.
> 
> 2. Only process requests with a _scxmlEventName header set as basichttp requests and use the respondable requests for everything else. This violates the draft for all requests directed at the access URI.
> 
> 3. Process everything directed at the access URI as a basichttp and everything with an additional path component as a respondable request. This violates the puristic REST view somewhat as the response from the access URI should tell you about all the more detailed URIs.
> 
> 4. Violate the draft and interpret everything as respondable requests.
> 

I just realized that we could also move the "access URI" to something like "http://hostname:firstFreePortAbove8080/interpreterNameWithEventualDigitsPrependedOrUUID/*basichttp*" and have everything else available for "respondable requests". All the draft requires is for "_ioprocessors['basichttp'].location" to contain the access URL. While the term "access URI" itself suggests some kind of URI where to direct all access, that's nowhere concretized.

> Does anyone see another possibility here to distinguish basichttp and respondable requests? I am inclined to go with the second option as the current basichttp approach seems insufficient anyway and 1.1 seems like too much for an application developer to be concerned about.
> 
> Best regards
> Stefan
> 
> [1] http://www.w3.org/TR/scxml/#BasicHTTPEventProcessor
Received on Thursday, 14 February 2013 13:19:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 February 2013 13:19:22 GMT