Re: client-server communication in JSSC

Le 13 maj 2013 à 16:29, Jim Barnett a écrit :

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

There were two big issues with I/O Processors that made me choose a seperate element:
1) symmetry
2) "fire-and-forget"

Symmetry means that events can be sent and received at any time from both ends; that could be addressed as you suggest, loosening the definition. Removing the requirement for a "location" field in I/O Processors would also help. Basically, allowing asymmetrical I/O would be perfect as far as I'm concerned.

The expression "Fire-and-forget" could be replaced by "Asynchronous" if that is indeed the intent of the specification. In fact, I'm sure you left <data src> in the spec only because there was no <fetch> to do it properly :p

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

I did define a new type, and I will again for WebSockets. The reason I used a "target" attribute instead of "src" is that "src", while it can contain a URI, must be treated the same way as <content>, and it is mutually exclusive with it. I can't see how the connection URI could be replaced by data.
I had another reason: with normal invoke types, you could use the "src" attribute to specify the code to be run, AND the "target" attribute to say where. You can't do that with just one attribute.

			David

Received on Monday, 13 May 2013 15:23:09 UTC