Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]

To get the ball rolling, let's take a careful look at the examples in 
Ugo's definition.  All of them have to do with separate transport level 
channels for a request and a response.  With the exception of polling 
for a response, none have to do with timing and all could be implemented 
with the requester waiting.  How about just

    One example of asynchronous request / response interactions occurs
    when the requester polls the server for a response.

?

thanx,
    doug

On 14-03-2003 15:58, David Booth wrote:

>
> Here are the results of the straw poll on the definition of 
> "synchronous".  Based on these results, I suggest that we:
>
> 1. Take definition ugo-2c (see 
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0074.html) as 
> a starting point.
> 2. See if everyone can agree to the essence of that definition.
> If so, then:
>   a. See if anyone wishes to make any minor modifications
>      (i.e., friendly amendments); and
>   b. Adopt the result.
> If not, then:
>   c. Try to combine two or more of the candidate definitions.

...

>> Definition ugo-2c
>> http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0386.html
>> Asynchronous: A request/response interaction is said to be asynchronous
>> when the request and response are chronologically decoupled. In other
>> words, the client agent does not have to "wait" for the response once
>> it issues the initial request. The exact meaning of "not having to
>> wait" depends on the characteristics of the client agent (including the
>> transfer protocol it uses). Examples include receiving the response on
>> a different thread, on a different socket, on a different end-point,
>> by polling the server, etc.
>>
>> Synchronous: The opposite of asynchronous.
>
...

Received on Friday, 14 March 2003 19:42:40 UTC