Re: The deep difference between request/response and fire-and-forget

On 1/12/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> 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