RE: Friendly amendment to friendly amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on "synchronous" definitions]

I'd be willing to go with this one.
 
-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Sunday, March 16, 2003 10:18 AM
To: www-ws-arch@w3.org
Subject: Friendly amendment to friendly amendment (was RE: Friendly
amendm ent #2c [Re: Straw poll on "synchronous" definitions]


 

	-----Original Message-----
	From: Anne Thomas Manes [mailto:anne@manes.net]
	Sent: Saturday, March 15, 2003 6:12 PM
	To: Walden Mathews; Christopher B Ferris; www-ws-arch@w3.org
	Subject: RE: Friendly amendment #2c [Re: Straw poll on
"synchronous" definitions]
	
	
	The biggest issue I have with Ugo's definition (and all the
others) is that they tie synchrony with blocking versus non-blocking.
Synchronous means "at the same time". Asynchronous means "not at the
same time". Whether or not the sender has to wait idly for a response is
a separate issue. 
	 
	An interaction (one-way, two-way, or multi-way) is synchronous
if the sender and receiver must communicate at the same time (the
reciever must be available to receive the message when the sender sends
it). A one-way message is asynchronous if the sender and receiver do not
need to communicate at the same time (the message may be stored and
delivered at a later time).  

I must say that I like Anne's wording that synchronous means that "the
receiver must be available to receive the message"  better than notions
of blocking or simultaneity.  What about changing Ugo's suggestion to:
 
Asynchronous: A request/response interaction is said to be asynchronous
when the request and response are chronologically and procedurally
decoupled. In other
words, the client agent can process the response at some indeterminate
point in the future when its existence is discovered, for example, by
polling, notification by receipt of another message, etc. 
 
Synchronous:  A request/response interaction is said to be synchronous
when the client agent must be available to receive and process the
response message from the time it issues
it issues the initial request until it is actually received or some
failure condition is determined. The exact meaning of "available to
receive the message" depends on the characteristics of the client agent
(including the transfer protocol it uses); it may, but does not
necessarily, imply tight time synchronization, blocking a thread, etc.