Re: The deep difference between request/response and fire-and-forget
Mark Baker <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
On 1/12/06, [email protected] <[email protected]> wrote: > Mark Baker writes: > > > In the case where the protocol supports optional responses, > > that won't be the case. > > I think you're missing my point. If you're assuming that both the client > and the "server" know in advance that the response is optional, then I > agree. Ok, but not all of my comments were premised on optional response support in the protocol. In fact, that was only one that was. > The situation I was modeling was one in which the decision to > respond was made by the server, which I think is what we've been > discussing. In that case, the client needs to know what to do. I agree > that there are pathological cases in which the client doesn't care about > any possible response, but I'm modeling the case where the client wants to > get the response if there is one. Oh, that wasn't clear to me. I thought you were modelling fire-and-forget? I certainly agree that with that scenario, there's a disconnect with request/response protocols (that don't support optional responses) for all the reasons you give. But I don't see how modelling that scenario helps make your case that "you cannot safely support true FAF on an underlying protocol that is req/resp". Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com