RE: How many states on each end?

+1 to Noah.  If we can get rid of much if not all of the state machines,
excellent.  You can see in the new one-way MEP and with my old proposals
for request-response how much easier the MEPs are with simplified state
machines.

I produced a version of the one-way that kept the state machine ONLY to
continue the state machines from the request-response MEP as that seemed
the right thing to do editorially, and shouldn't be interpreted as a
pro-keeping the stance from me.

Cheers,
Dave

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On
> Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Tuesday, April 04, 2006 1:51 PM
> To: David Hull
> Cc: xml-dist-app@w3.org
> Subject: Re: How many states on each end?
> 
> 
> David Hull writes:
> 
> > The intermediate states only seem useful if external entities want
> > to query whether anything is in progress, or conversely if the node
> > wants to notify them on transition, but how finely do we want to
> > slice this?  We could easily add "envelope built" or "headers
> > processed" or whatever and argue for each of them.  I could
> > particularly see an argument for "headers processed" in the context
> > of WSA and fault handling.  However, I would prefer to keep the MEP
> > definition minimal and layer finer distinctions on top of it.  We
> > can always define, say, "receiving" and "headers processed" later
> > and define them as equivalent to "init" for purposes of determining
> > overall success and failure.
> 
> The state machines for request/response seem to me at risk of being
overly
> detailed in their attempts to explicitly model streaming.  In the case
of
> one-way, I'm not convinced that we need to talk about state machines
at
> all, or to model any of the intermediate states in which a message is
> partially sent, streaming, or whatever.  It seems to me that the
> description of the sender is roughly:  the envelope is made available
as
> outboundMessage and a destination is provided.  Why do we need to say
> anything more than "The sender attempts to transmit the message to the
> destination.  The sender MUST include in the message the envelope
infoset,
> and MAY include the destination address or other binding-specific
> information.    The binding MAY but need not provide error information
to
> the sender in the case that the message is not transmitted
successfully.
> The binding and its impementation at the sender MAY provide for
streaming
> of large messages, such that the first part of the message is
transmitted
> in parallel with the preparation of the remainder."   And, if you
believe
> in talking about the timing, which I understand remains controversial:
> "This binding is not intended for use in situations where completion
of
> the transmission at the sender will require explicit action or
> acknowledgement (at any level) from the receiver."
> 
> I think that's about what we need at the sender.  At the receiver, I
would
> think:
> 
> "This paragraph describes the operation of a receiving node using the
one
> way MEP.  For each received message, the message envelope infoset MUST
be
> made available to the receiver.  Additional binding-specific
information,
> such as the destination address, MAY also be made available.  The
binding
> MAY but need not alert the receiver to situations in which a message
was
> known to have been lost due to network failure, lack of available
buffer
> memory, or other binding-specific error.    The binding and its
> impementation at the sender MAY provide for streaming of large
messages,
> such that the first part of the message is provided to the receiving
> application in parallel with the reception from the network of the
> remainder.
> 
> I think that's about all we need in place of what would have been the
> state machines.    It seems simple, declarative, and sufficient to
signal
> the ability both to stream and to ignore errors if desired.
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
>

Received on Wednesday, 5 April 2006 08:21:24 UTC