RE: Draft language on MEPs, synchronous, and asynchronous.

what you describe is a feature of the browser application not of the
protocols.

Martin.

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Monday, May 05, 2003 1:43 PM
> To: 'Martin Chapman'; Cutler, Roger (RogerCutler); Geoff Arnold;
> Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
>
>
> May be we are divided by the same words.
>
> Try the following experiment.
>
> Type in a URL in a browser (lets say the page the page takes some time to
> appear)
> Before the page apperas type in the same URL, and press return.
>
> Now, what happened to the first connection? Is it being multiplexed? Will
> you see two pages? Of course, you won't - because the first page
> invocation
> was aborted.
> This behavior, to me, is an attribute of synchrnous invocation of
> the page.
>
> You may type in the same URL on a different browser window. In this case,
> there are two
> communication channels, because the sender of the message is
> different. Will
> you be able
> to see the same page in two browsers? Yes.
> Does it mean the page invocation is not synchrnous? No.
>
> BTW, try defining "multiplexing:-)"
>
> Regards,
> -Suresh
> Sterling Commerce (on loan to RosettaNet)
> 469 524 2676 (O), 469 323 0234 (Cell)
>
>
>
> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Monday, May 05, 2003 3:03 PM
> To: Damodaran, Suresh; Cutler, Roger (RogerCutler); Geoff Arnold;
> Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
>
>
> I thought I had. It is possible in synchronous systems for A to send a
> request to B even if a response to a previous request from A to B has not
> yet been received; it's called multiplexing.
>
> Martin.
>
> > -----Original Message-----
> > From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> > Sent: Monday, May 05, 2003 12:39 PM
> > To: 'Martin Chapman'; Cutler, Roger (RogerCutler); Geoff Arnold;
> > Champion, Mike
> > Cc: www-ws-arch@w3.org
> > Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> >
> >
> > Please explain teh exact situation in which this definition is wrong
> >
> > Regards,
> > -Suresh
> > Sterling Commerce (on loan to RosettaNet)
> > 469 524 2676 (O), 469 323 0234 (Cell)
> >
> >
> >
> > -----Original Message-----
> > From: Martin Chapman [mailto:martin.chapman@oracle.com]
> > Sent: Monday, May 05, 2003 11:39 AM
> > To: Cutler, Roger (RogerCutler); Geoff Arnold; Champion, Mike
> > Cc: www-ws-arch@w3.org; Damodaran, Suresh
> > Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> >
> >
> > The sync/async differentiation below is technically wrong.
> > It is entirety possible that a client may have two requests
> > outstanding and
> > for both of them
> > to be synchronous, so this implied serialization is just not accurate. I
> > suggest we
> > stick with Geoff's proposal and not waste anymore time on this.
> >
> >
> > Martin.
> >
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Cutler, Roger (RogerCutler)
> > > Sent: Sunday, May 04, 2003 11:30 AM
> > > To: Geoff Arnold; Champion, Mike
> > > Cc: www-ws-arch@w3.org; Suresh_Damodaran@stercomm.com
> > > Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> > >
> > >
> > >
> > > I would have thought that email is, by its essence, always
> asynchronous,
> > > that most MOM systems have well-defined synchronous and asynchronous
> > > modes, and that the last example is a "scheduled asynchronous
> > > communication" and clearly asynchronous.  I do not think that
> > > "synchronous" is in any way synonymous with "scheduled" and I don't
> > > think I can recall any candidate definitions in which that
> was the case.
> > >
> > > I'm sorry, I still think this is just giving up and that in fact the
> > > terms have a domain of validity in which they can be
> rigorously defined.
> > > It seems to me that doing so, and if possible defining some
> domain where
> > > they are not meaningful (although I really haven't personally
> understood
> > > why there would be such a domain or seen it described in a way that I
> > > understand) would be more productive.
> > >
> > > I think that Suresh's definition, which I had not seen
> before, is pretty
> > > good.  The one thing that might be questionable is that it
> uses the word
> > > "channel".  I do not really know what a channel is.  Possibly
> > > understanding that would help to define the domain in which
> > > synch/asynch has meaning.  However, if "synchronous" depends
> on having a
> > > channel, I don't exactly see the problem with using the term
> > > "asynchronous" for situations where the concept of channel is somehow
> > > not relevant.
> > >
> > > For convenience, here is Suresh's definition again.  Note
> that it rather
> > > explicitly defines its domain of applicability with the
> phrasee "over a
> > > communication channel" (whatever that means).
> > >
> > > Synchronous: An entity A  communicates with entity B
> synchronously over
> > > a communication channel if and only if A requires a response
> back from B
> > > and A does not initiate another communication to B using the same
> > > communication channel before it receives that response.
> > >
> > > Asynchronous: When A communicates with B  asynchronously, A does not
> > > always require a response back from B. Irrespective of whether A
> > > requires a response or not, A may initiate another
> communication to B on
> > > the same communication channel.
> > >
> > > *"communication" can be a message or a signal.
> > >
> > > Here is a version that I have word-smithed a bit.
> > >
> > > Synchronous: An entity A communicates with entity B
> synchronously over a
> > > communication channel if and only if A requires a response back from B
> > > and A does not initiate another communication to B using the same
> > > communication channel before it receives that response or the
> > > communication has failed.  Entity A may consider the communication to
> > > have failed if it does not receive a response back in some length of
> > > time.
> > >
> > > Asynchronous: When A communicates with B  asynchronously, A may not
> > > require a response back from B. Whether A  requires a
> response or not, A
> > > may initiate another communication to B on the same communication
> > > channel at any time.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Geoff Arnold [mailto:Geoff.Arnold@sun.com]
> > > Sent: Saturday, May 03, 2003 6:02 PM
> > > To: Champion, Mike
> > > Cc: www-ws-arch@w3.org
> > > Subject: Re: Draft language on MEPs, synchronous, and asynchronous.
> > >
> > >
> > >
> > > > I for one would be happy to substitute something like:
> > > >
> > > > MEP's involving that require a response from the responder
> back to the
> > >
> > > > initiator before the initator can initiate another
> communication that
> > > > responder using the same communication  channel are frequently
> > > > referred to a "synchronous."
> > > >
> > > > I see that as a friendly amendment that defines "closely coupled in
> > > > time"
> > > > more rigorously.
> > >
> > > I actually see this as an excellent argument *against* trying to get
> > > more rigorous. First, the "same communication channel" is hopelessly
> > > transport-specific. (Try that over MOM or SMTP!) Second, a MEP that
> > > requires me to send you a message on the third Tuesday of
> every month is
> > > perfectly *synchronous*. "Closeness" of coupling is a relative thing.
> > >
> > > Used informally, the terms can be usefully descriptive. Let's leave it
> > > at that.
> > >
> > >
> > >
> > >
> > >
> >
>

Received on Monday, 5 May 2003 18:43:41 UTC