> Synchronous request-response is suboptimal for many existing and
> emerging uses. In the long run, conversational async message based
> protocols are the way to go. SOAP acknowledges this in the spec but
> doesn't really achieve it with it's only binding of HTTP. I much prefer
> Blocks/BXXP ("beep") or a future version of Jabber's protocol.
Oh, I agree *whole heartedly* --- my last several years have largely been spent
pushing loosely-coupled async communications patterns. (Activerse was all about the
realization that there are *application patterns* that require 1-N async event
notification; but at the end of the day, those are easily implemented given a
point-to-point sync RPC, like HTTP.) My point in the previous message is to note
that a synchronous, request-response comm protocol as a primitive is provably,
formally sufficient to implement any other models atop it, such as async
message-based, async generative, etc. Just ask Ro! :-) In other words, all you need
is --- not love! --- HTTP. ;-) And HTTP with any *1* method, at that.
Converts are the most zealous,
jb
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:13:21 PDT