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 Sunday, 12 May 2013 19:54:53 UTC