RE: Response envelope optional vs. response optional

The point of defining a generic "request-optional-response" MEP and
binding to one-way transport is to provide properties for the request
and for the response.  If there's a one-way with no response, then the
request will have been sent and the response will be empty.  

Again, the point is to have a single property for the "request" that
spans all underlying protocols.  

This is not cheese sandwich with no bread at all.  The English language
can express cheese on it's own, or in conjunction with bread to make a
sandwich.  A more appropriate analogy is to imagine that English doesn't
have the 2 notions of standalone Cheese and Cheese sandwich, say English
only has "standalone cheese" or "cheese sandwich", aka request-only or
request-response..  My breathtaking idea is to introduce the notion that
cheese can be used as a word on it's own, like "cheese with or without
bread", aka "request-optional-response".

Cheers,
Dave
> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On
> Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Wednesday, December 21, 2005 4:50 PM
> To: David Hull
> Cc: Anish Karmarkar; xml-dist-app@w3.org
> Subject: Re: Response envelope optional vs. response optional
> 
> 
> David Hull writes:
> 
> > The "cheese sandwich with no bread" issue is slightly
> > different.  I don't like the idea of defining a generic
> > "request optional-response" MEP and binding it to a one-way
> > transport, where we know there will never be a response.
> 
> I agree completely!  It's the application receiving the request that
> decides whether there will be a response.  Let's assume you send a
request
> through the DHOneWayTransportBinding and the application does generate
a
> response.  The binding can't do what it's required to do, which is
deliver
> the response.  The response envelope is optional only in the sense
that
> the application may say "I'm not sending one".  If the application
tries,
> the binding must deliver.
> 
> Of course, there may be rare cases where you have a very special
purpose
> implementation (e.g. an embedded system running only one application)
and
> you know that the app. will never send a response.  In that case, I'd
say
> you don't have to write the code in the binding that you know will
never
> be called.  Otherwise, the binding must be capable of sending a
response
> envelope; the app will decide whether to send one.  Right?
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
>

Received on Monday, 9 January 2006 22:44:40 UTC