Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomments 1,2

[Doug Bunting <Doug.Bunting@Sun.COM>]

Jacques,

Please see below

On 15-Jul-04 17:15, Jacques Durand wrote:
...

> Deliver:
> 
> An abstract operation that transfers the payload of one Reliable Message
> from Receiving RMP to Consumer.  For example, in one specific
> implementation choice, the payload is placed into a queue by the Receiving
> RMP to be consumed by an application component.
> 
> <JD> So you propose to not use anymore the expression "making available".
> In that case we should warn that the notion of "transfer" above must also
> be understood in an abstract way, as a transfer of control (or of 
> responsibility) on the payload,
> not necessarily as a physical transfer which may take place later
> (in which case we may not want to wait for this to happen before sending 
> the Ack).
> E.g. an RMP may "deliver" by just setting a flag on
> payload stored in a persistent store, meaning availability to a COnsumer 
> which
> may later complete the actual transfer by querying the store.
> </JD>

Whether payloads or control of payloads is transfered is a very low 
implementation detail that does not matter when we are talking about 
abstract operations on abstract components.  I believe this only confuses 
the specification.

> Notify:
> 
> An abstract operation that transfers a failure status or contained payload
> of one Reliable Message from Sending RMP to Producer.  The transfered
> status might include an indication the Sending RMP was unable to reliably
> deliver the message.  The Sending RMP is NOT REQUIRED to invoke this
> operation for every Reliable Message submitted; it MAY invoke Notify for a
> subset of the completed Submit operations.
> 
> <JD> the last sentence ("it MAY...") is not clear, and talks of 
> correlation between
> these ops that I believe should be addressed later in the doc in a more 
> informed context,
> e.g. section 2.2.
> Also we may want to move the requirements
> (statements using the RFC keywords) out of these definitions, and in a 
> more prescriptive section
> like 2.2. The prescriptive section (2.2) should also say the most basic: 
> that an RMP MUST
> be able to invoke Notify (regardless how the op is implemented) as well 
> as Deliver.
> The other operations (Submit, Respond) are to be invoked from outside.</JD>

Moving these sentences elsewhere is fine.  I am not sure what is missing 
(or where) with regard to your last sentence.

...

> Respond:
> 
> An abstract operation that transfers the payload of one Response Message
> from Consumer to Receiving RMP.  When supported in the protocol, this
> payload data will be carried together with RM Reply headers (see below).
> The Consumer is NOT REQUIRED to invoke this operation for every Reliable
> Message delivered; it MAY invoke Respond for a subset of the completed
> Deliver operations.
> "
> <JD> same remarks as for Notify. Also the 2nd sentence seems not at its 
> place in this
> a definition, whch I believe does not need to mention all the rules 
> associated with these ops.
> I propose to keep just the 1st sentence, in the def.</JD>

In another email, you agreed with the general use of forward references 
from this section.  The second sentence above is a forward reference to the 
rules you mention, not those rules.

> thanx,
>         doug

..