W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

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

From: Mark Baker <distobj@acm.org>
Date: Thu, 12 Jan 2006 20:51:54 -0500
Message-ID: <c70bc85d0601121751p6c7dfdy72b122771f19dce0@mail.gmail.com>
To: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
Cc: xml-dist-app@w3.org

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 Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Friday, 13 January 2006 01:51:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC