- 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>
> 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 UTC