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.