Is it a transport protocol or not?
Definitely not a transport protocol. It’s a state transfer protocol.
The difference is this: the HTTP interface is vague and the Linda interface is specific. Linda has precise, simple semantics. The possible range of behaviors exhibited in Linda-based systems benefit from being layered on *top* of those precise, simple semantics.
Hmm, I’m not seeing it. How is get, put, and post any more vague than rd, write, and take? All have “precise, simple semantics”. IMO, the only really important difference between them is that the former are operations defined on a more general abstraction than the latter; the resource for REST, and the tuple space for Linda. If it helps, I drew that relationship once upon a time.
Also, regarding Linda, I don’t see how the range of behaviours is a result of layering. Perhaps this is just a nomenclature problem, but I attribute the wide range of behaviours to the generality of the Linda interface. For example, if your operation was getStockQuote(), then you’re only going to be able to use it for stock quotes. If it were getQuote(), then that would be more general, as you could also use it for insurance quotes too. If it were GET or rd, well, you could use it for most anything, couldn’t you?
One other point I want to respond to;
Vanessa Williams provides an elaboration of HTTP for a tuple space application protocol. As I understand REST this should therefore provide the application protocol of a tuple space on the architectural style of REST using the HTTP transport/application protocol mix. In this case the advantage of using REST and HTTP is supposed to be found in the hardware and software that would already be in place between the client and the server.
I wouldn’t say that’s what Vanessa did. What I would say she did, is that she described how one could build an HTTP gateway (a Facade) to a tuple space system; identifying each space with a URI, and mapping HTTP operations to tuple space operations.
Offline, I suggested to Patrick that if we took Linda to the IETF to standardize, that we’d be placed in the Applications Area where we’d be tasked with defining “TTP”, the “Tuple Transfer Protocol”. This application protocol would include operations such as READ, WRITE, TAKE, etc.. Perhaps it might even accomodate extensions so that somebody could, in the future, define the “TTP-NOTIFY” extension protocol which added the “NOTIFY” operation. That would also, as with HTTP, most definitely not be a transport protocol … though I’m sure most SOAP proponents would want to treat it like one. 8-)
no comment until now