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

RE: The deep difference between request/response andfire-and-forget

From: David Orchard <dorchard@bea.com>
Date: Mon, 30 Jan 2006 12:14:56 -0800
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C864F83@repbex01.amer.bea.com>
To: <xml-dist-app@w3.org>

I assume that when we talk about doing a true fire and forget mep, it
would be as part of rechartered XMLP.  

Maybe a way of looking at recharted xmlp would be to "cleanup" meps
which could include adding f-a-f and refactoring the meps as I've been

Though I still am leery of supporting rechartering to do an mep that we
haven't had a single external request to do and we wouldn't produce a
binding that uses.


> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Thursday, January 26, 2006 5:33 PM
> To: David Orchard
> Cc: Mark Baker; Patrick R. McManus; Rich Salz; xml-dist-app@w3.org
> Subject: RE: The deep difference between request/response andfire-and-
> forget
> David Orchard writes:
> > More to the point, I don't see why we'd need an request-optional-
> > soap-response mep AND a f-a-f mep where f-a-f is interpreted as you
> > suggested on the server.
> ...because when we implement SOAP on true FAF transports like UDP, and
> maybe some flavors of Jabber (I have to go back and look at that)
> want the true FAF MEP and probably not the Req/Resp (I.e. because
> Req/Resp, as we keep reminding ourselves, requires the transport to
> how to address responses, which in general UDP does not provide.)  FAF
> the natural MEP and should be used on one-way transports;  Req/Resp
> Response-only (which is more properly named
> Request/ResponseWithEnvelopeInResponseOnly) are the natural MEPs and
> should be used on Request/Response protocols like HTTP.
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
Received on Monday, 30 January 2006 20:15:38 UTC

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