OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Issue 129: Define "discard"


Perhaps I'm getting confused.  Could you narrow the text below to the 
current proposal and only the current proposal?

thanx,
    doug

On 15/06/06 14:19, Doug Davis wrote:
>
> My latest one doesn't use 'deliver' but I can go with your "discard" 
> definition if you could
> just write it in the scope of the text in that section.  Could you 
> propose some new text for
> the monkey to use?
>
> -Doug
>
>
>
> *Doug Bunting <Doug.Bunting@Sun.COM>*
> Sent by: Doug.Bunting@Sun.COM
>
> 06/15/2006 05:09 PM
>
> 	
> To
> 	"Durand, Jacques R." <JDurand@us.fujitsu.com>
> cc
> 	Bob Freund-Hitachi <bob.freund@hitachisoftware.com>, Doug 
> Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org
> Subject
> 	Re: [ws-rx] Issue 129: Define "discard"
>
>
>
> 	
>
>
>
>
>
> My concern is both
>
>    * effectively re-opening i106 and re-introducing more use of the
>      term "deliver"
>    * introducing an unnecessary, otherwise-unspecified, and untestable
>      separation between the RMD and the AD; this is an implementation
>      issue we shouldn't be prescribing
>
> "Discard" should really mean the target application will, however it and
> the RMD are implemented, just doesn't process the message if it falls
> into one of the classes described below.
>
> thanx,
>    doug
>
> On 15/06/06 12:38, Durand, Jacques R. wrote:
> >
> > Although expressing these defs in terms of delivery” would be very
> > explicit, it reintroduces a notion of contract between RMD and AD
> > which would be odd here if there is no other mention of delivery in
> > the specification (even if only a general statement on the duty to
> > “deliver” according to some external DA).
> >
> >  
> >
> > If a clear correlation between “delivery” and the values of this
> > element need be established, that seems to fall under an out-of-bound
> > agreement (like for DAs), and does not belong to this spec.
> >
> >  
> >
> > So I propose:
> >
> >  
> >
> > /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior
> > This optional element, if present, specifies the behavior that the RM
> > Destination will exhibit
> > upon the closure, or termination, of an incomplete sequence. It should
> > be taken as a hint and does not entail any commitment from the RMD
> > unless associated with an out-of-bound agreement or policy.
> >
> > A value of “DiscardEntireSequence” indicates that none of the messages
> > for the sequence will
> > be processed further by the RM Destination if the sequence is closed,
> > or terminated, when there are one
> > or more gaps in the final SequenceAcknowledgement
> >
> > A value of “DiscardFollowingFirstGap” indicates that messages in the
> > sequence beyond the first
> > gap will  not be processed further by the RM Destination when there
> > are one or more gaps in the
> > final SequenceAcknowledgement.
> >
> > The default value of “NoDiscard” indicates that all acknowledged
> > messages in the sequence will be
> > processed further by the RM Destination.
> >
> >  
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com]
> > *Sent:* Tuesday, June 13, 2006 4:37 AM
> > *To:* Doug Davis; ws-rx@lists.oasis-open.org
> > *Subject:* RE: [ws-rx] Issue 129: Define "discard"
> >
> >  
> >
> > I don’t like the idea of introducing deliver again.  I106 besides this
> > text was all about expunging the “deliver” word and instead
> > substituting the concept of “transfer”
> >
> > Discard seems perfectly fine to me since the protocol is concerning
> > transfer and not delivery.
> >
> > As an alternative, you might consider “messages will be dropped with
> > no further processing” or some such.  But PLEASE keep delivery out of
> > the text.
> >
> > Thanks
> >
> > -bob
> >
> >  
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Doug Davis [mailto:dug@us.ibm.com]
> > *Sent:* Monday, June 12, 2006 12:50 PM
> > *To:* ws-rx@lists.oasis-open.org
> > *Subject:* RE: [ws-rx] Issue 129: Define "discard"
> >
> >  
> >
> >
> > I like the idea of just getting rid of the term "discard", so how
> > about this (note I added "terminate" to the text too):
> >
> > /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior
> > This optional element, if present, specifies the behavior that the RM
> > Destination will exhibit
> > upon the closure, or termination, of an incomplete sequence.
> >
> > A value of “DiscardEntireSequence” indicates that none of the messages
> > for the sequence will
> > be delivered by the RM Destination if the sequence is closed, or
> > terminated, when there are one
> > or more gaps in the final SequenceAcknowledgement
> >
> > A value of “DiscardFollowingFirstGap” indicates that messages in the
> > sequence beyond the first
> > gap will  not be delivered by the RM Destination when there are one or
> > more gaps in the
> > final SequenceAcknowledgement.
> >
> > The default value of “NoDiscard” indicates that all acknowledged
> > messages in the sequence will be
> > delivered by the RM Destination.
> >
> >
> > thanks
> > -Doug
> >
> >
> > *"Marc Goodner" <mgoodner@microsoft.com>*
> >
> > 06/09/2006 11:39 AM
> >
> >                  
> >
> > To
> >
> >                  
> >
> > Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> >
> > cc
> >
> >                  
> >
> >  
> >
> > Subject
> >
> >                  
> >
> > RE: [ws-rx] Issue 129: Define "discard"
> >
> >  
> >
> >  
> >
> >                  
> >
> >  
> >
> >
> >
> >
> > Doug,
> >  
> > This seems wordier than necessary.  The text added for
> > DiscardEntireSequence does not use the definition you added for
> > discard at all. The other two values seem like they would benefit from
> > simply changing the word discard to not deliver.
> >  
> > I don’t think it is necessary to prepend “note” to the sentence added
> > below or “quote” any of the words in this proposal.
> >  
> > *From:* Doug Davis [mailto:dug@us.ibm.com] *
> > Sent:* Thursday, June 08, 2006 12:03 PM*
> > To:* ws-rx@lists.oasis-open.org*
> > Subject:* [ws-rx] [NEW ISSUE] Define "discard"
> >  
> >
> > Title: Define "discard"
> >
> > Description/Justification:
> > In WD13.pdf section 3 - line 308++ - should we define "discard" - 
> its not
> > clear to me that we mean the discarded messages will NEVER (and have
> > never) be delivered to the AD, instead of just "from now on the RMD
> > won't deliver them".
> >
> > Target: wsrm spec
> >
> > Type: design
> >
> > Proposal:
> >
> > Modify the text for IncompleteSequenceBehavior to be (new stuff in 
> bold):
> > (Chris/Bob is this new stuff consistent with what you guys wanted?)
> >
> > /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior
> > This optional element, if present, specifies the behavior that the RM
> > Destination will exhibit upon the
> > closure of an incomplete sequence.  *For the purposes of defining the
> > values used, the term
> > 'discard' refers to the RM Destination never delivering a particular
> > message to the AD.*
> >
> > A value of “DiscardEntireSequence” indicates that the entire sequence
> > will be discarded by the RM
> > Destination if the sequence is closed when there are one or more gaps
> > in the
> > SequenceAcknowledgement/Final. *Note, this means that the RM
> > Destination will not deliver any* *
> > messages to the AD until the final SequenceAcknowledgement is
> > determined and there are no
> > gaps in it.*
> >
> > A value of “DiscardFollowingFirstGap” indicates that messages in the
> > sequence beyond the first gap will
> > be discarded by the RM Destination when there are one or more gaps 
> in the
> > SequenceAcknowledgement/Final.
> >
> > The default value of “NoDiscard” indicates that no acknowledged
> > messages in the sequence will be
> > discarded by the RM Destination.
> >
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]