Paul Prescod has submitted a request for an ETCON BOF. Hopefully shortly the details will be posted here. Meanwhile I have a few suggestions for topics to be discussed.
Don Box commented that
"If it takes three minutes for a response, it is not really HTTP any
more". In situations where responses may take five days, is it
possible to apply the architectural style that made the web so successful, or is
a new approach required? Put another way, is REST tightly bound to HTTP or
can the architectural principles it embodies be applied to other protocols?
When the request and response are sufficiently temporally separated, one
essentially end up with the equivalent of UDP datagrams. Is it possible to layer
on the equivalent of what TCP provides in terms of error recovery, flow control,
and reliability in such a context?
The REST wiki suggests
that the REST architectural style is most closely related to that of TupleSpaces.
One important difference is that in TupleSpaces the sender does not identify the
recipient. Data is addressed and routed based on content. Is there a
place for such a model in "Alternative Web Services Architectures"?
BOF topic - long lived conversations
I think talking about whether REST applies to long lived conversations would be a great topic.
There has been discussion about this on the REST forums, but it would be good to go over it again.
As for HTTP, there is a response code of '202 Accepted' which is used to indicate that the request is being processed asynchronously - which leads to the 'five days for a response' situation. What hasn't happened is for a large number of people to implement a standard approach for sending that final response message to the sender - but there are lots of ways to do that (take a look at the REST discussion groups).
Mike
SOAP vs. REST Resources
I've started a SOAP vs. REST Resource page:
http://www.myspotter.net/links.html
REST Protocol Alternatives
"can the architectural principles it embodies be applied to other protocols"
I think the answer is obviously yes. I like the thinking behind REST but I've always been amazed that its proponents are so adamant about marrying it to HTTP. BEEP provides a solid, modern foundation for designing an application protocol that embodies the REST architectural style. You might even claim that the original InvisibleWorlds product concept, for which BEEP was designed, had a REST flavor.
Regarding your observation about UDP, note that APEX, which is built on BEEP, provides an application (protocol) layer best-effort datagram delivery service.
Marshall Rose has done the Internet community a great service by synthesizing 20 plus years of application protocol experience into a simple, clean framework for next generation protocols. We should leverage that effort rather than tweaking and swizzling HTTP into something it was never intended to be.