RE: client-server communication in JSSC

David,
  Those are both interesting extensions, and should be considered for inclusion in a future version of the specification, if there's interest in creating one.  A couple of quick thoughts on the syntax:

1.  For <fetch>, we might be able to define a new Event I/O Processor, instead of adding a new element.  It's important to the definition of <send> that it not block waiting for a response, but the <fetch> response arrives asynchronously in the external event queue, so we could define the HTTPRequest Event I/O Processor to do that.  Unlike other Event I/O Processors, the HTTPRequest processor would only accept events in response to requests that it had generated.  

2.  For the extension to <invoke>, it might be possible to define a new <invoke> type.  The meaning of the 'src' attribute is type-specific, and there is no requirement that it be taken as specifying markup.  

We'd have to work through the details on these, of course, but the functionality certainly looks worthwhile.  

- Jim

-----Original Message-----
From: David Junger [mailto:tffy@free.fr] 
Sent: Sunday, May 12, 2013 3:54 PM
To: Voice Public List
Subject: client-server communication in JSSC

We discussed some client-server extensions a while ago (<fetch> and <respond>, both are now implemented).
First, I wanted to link to the spec I have published for <fetch> so anyone interested can review it, link to it, and hopefully implement it and use the same namespace.
http://www.jsscxml.org/fetch.html

I also just finished implementing and testing something I wanted to do a long time ago. I mentionned EventSource before on this list. Well, I have designed an extension to <invoke> semantics that allows you to "invoke" a connection with a specific target URI instead of invoking a subsystem with specific source code. I used <invoke> instead of a new element this time because a new element would have been a near exact copy of <invoke>, and <invoke> has hooks everywhere.
Besides, the connection-like <invoke> really behaves like an invoke, with <finalize> and done events and all that, except that you do not specify the code that runs on the other side of the connection. Instead, you can do what basic <invoke> doesn't let you: say *where* the other system is running. I know that some people have been looking for something like that and I hope you'll like how I did it (and/or suggest how to do it better).
http://www.jsscxml.org/connect.html

So that is a bit abstract. In practice, I have implemented a specific connection protocol to begin with, the one used by EventSource in Web browsers. It is a one-way connection (you can only receive events over it, not send) but it's a lot easier to implement than WebSockets (which is planned nonetheless, but for later) and it has its own spec, linked from the previous link (or just look up on the JSSC homepage).

I'd also like to suggest to server-side SCXML developers that they implement the other side of EventSource (sending events to a client over event-stream). There are two ways to use it. One is the invoke extension I have proposed, if you have SCXML on the client too. The other is to use the bare EventSource interface, that produces DOM Events from the event-stream. And that, in fact, is why server-side SCXML implementation might want to support <send type="DOM"> after all :)

			David

Received on Monday, 13 May 2013 14:30:27 UTC