- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 29 Mar 2006 15:25:30 +0200 (MEST)
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
On Tue, 28 Mar 2006, Anish Karmarkar wrote: > > At the Cannes F2F I took an action to start a discussion on what > Fire-and-Forget (FAF) MEP means. This email is intended to start that > discussion. > > IIRC, this was in the context of whether we need two different MEPs: one-way > MEP and FAF; and whether a FAF MEP has no timing issues (how long does the > sender have to wait?) compared with one-way MEP. Hum, to me it boils down to the issue of channels used for messages and errors, in ROR, we defined it as no channel back for messages, but errors may flow through the underlying protocol native "reply" system. In the one-way MEP case, no errors or replies (SOAP ones) can use the native transport "reply" (if present, UDP won't have it anyway). In some cases, the transport itself can signal that it was not able to send the message, at this point it is unclear how > I'm not convinced that we should construct MEPs with any builtin timing > constraints (and any programming API assumptions). It has been mentioned that Well, if we define One-way as just sending the message, and not waiting for any reply or error message, there is no timing issue, the only timing discussion is in the ROR case, as you may wait for either a response or an error message. > I would also like to mention that I think one can indeed bind a FAF MEP (or a > one-way MEP for that matter) to a protocol such as HTTP . In this case, at FAF should be a property of the underlying protocol, and even in that case there are different kinds of FAF... -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 29 March 2006 13:26:09 UTC