Re: Regrets for 1 Feb XMLP Telcon (was: Re: Comments on the "drop response-only" Part 2 draft)

On Wed, 25 Jan 2006, noah_mendelsohn@us.ibm.com wrote:

>> but must send regrets for next week.
>
> I'm afraid that still holds.  I hope you will all give serious
> consideration to my comments and conclusions posted today at [1], and also
> to the thread on the differences between one way and request/response. I'm
> increasingly convinced that the position I took in my original note [2] is
> pretty close to correct as stated, both as general philospophy and as
> specifically applied to HTTP (see especially [3]).  Thanks.

My position is that replacing Request/Response by something that has 
options. If you have a program that use Request Response and is hard wired 
to always have a response, then changing to "ah you _may_ have a response" 
is a big conformance change.

Also if we push a bit the optional request/optional response, to do 
something like request*/response*, we define a MEP that covers all kind on 
interaction that may happen between two nodes (including multicast).
In that case, MEPs are no longer useful and should be removed.

The fact that some implementation may be using one way messaging in HTTP 
in the current framework needs to be addressed, but if it disrupts the 
current understanding of MEPs, then this case needs to be addressed with 
the implementers to fix issues like the a-priori knowledge from the client 
of the MEP used. And the fact that the one way MEP is done as "fire and 
forget" or with ackowledgement that the message has been received is just 
a property of the "transport" used, but it doesn't change the overall 
meaning of the MEP a the SOAP level.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Monday, 30 January 2006 17:23:59 UTC