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

Just to make my objection more clear:

Definitions:

Synchronous: Blah, blah, blah.

Asynchronous:  That which is not synchronous.

Aha!  A barbershop quartet is not blah, blah, blah.  A used diaper is
not blah, blah, blah.  My maiden aunt is not blah, blah, blah.  Thus
they are all asynchronous.

Come on ... At least let's get my maiden aunt out of the picture.

-----Original Message-----
From: Cutler, Roger (RogerCutler) 
Sent: Friday, March 14, 2003 9:26 PM
To: Walden Mathews; David Booth
Cc: www-ws-arch@w3.org
Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]



Yeah, this is fine, too. But I still won't accept defining one as the
negation of the other.

OK -- so how about this one for synchronous and Ugo's for asynchronous.
It's a bit repetitive -- but so the hell what?

Pardon me.

-----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net] 
Sent: Friday, March 14, 2003 7:28 PM
To: David Booth
Cc: www-ws-arch@w3.org
Subject: Re: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]



> > 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.
> >
> ...


I have two recommendations:

(1) reverse the nature of the definitions to the positive mode, so that
asychronous is defined in terms of synchronous instead of vice versa.
This is mainly about refactoring out a logical double negative.  But
something interesting happens with the examples. Please comment (see
below).

(2) be careful about stating the nature of the relation of asynch to
synch.  "Opposite" is ambiguous.  It's really set difference. If you
subtract the synchronous cases from all r/r cases, you are left with the
asynchronous cases.  Isn't that a clearer test?

Thusly:

Synchronous:
A request/response interaction is said to be synchronous when the
request and response are chronologically coupled.  In other words, the
client agent has to "wait" for the response once it issues the initial
request.  The exact meaning of "wait" depends on the characteristics of
the client agent (including the transfer protocol it uses).  Examples
include waiting for the response in a different thread, on a different
socket or end-point, or by polling the server.

Asyncronous:
A request/response interaction that does not meet the constraints of a
synchronous interaction (above) is said to be asynchronous.


FWIW,

Walden

Received on Friday, 14 March 2003 22:34:14 UTC