Re: [wsrm] Rel-102 (Persistence requirements)

["iwasa" <kiwasa@jp.fujitsu.com>]

Agree to remove section2.7.
One question is whether we want to move the last sentence to
somewhere else or not.

By the way what "The current proposal:" means?

Thanks,

Iwasa

----- Original Message ----- 
From: "Jacques Durand" <JDurand@us.fujitsu.com>
To: "WSRM (E-mail)" <wsrm@lists.oasis-open.org>
Sent: Wednesday, February 11, 2004 9:35 AM
Subject: [wsrm] Rel-102 (Persistence requirements)


> Rel-102 (Persistence requirements):
>
> Overall proposal:
>
> just remove the section 2.7, because it is redundant with what RM features
> require. I.e. when implementing most of these features, persistence will
> automatically
> appear as necessary. It is an implementation aspect.
> In addition, some persistence requirements may actually NOT be necessary
> to satisfy some RM requirements, i.e. are encroaching on implementation
> choices.
>
> Details:
>
> <JD>
> - the Sender side has to be able to resend the same message (retry).
> We don't need to state more than that.
> How is that achieved, is an implementation decision. Some form of
> persistence is
> likely to be needed, but after all there may be alternatives that we
should
> not
> preclude (e.g. the RMP fetching messages to be resent, from an external
> store...)
> - Receiver side: same proposal: persistence is implied by the RM features.
> In addition, here again the current proposal in the Feb 4 issue list, will
> unnecessarily
> restrict implementation choices.
> </JD>
>
> The current proposal:
> "When supporting Guaranteed Message Ordering, the receiver is REQUIRED to
> persist
> out of order messages until one of the following conditions are met:
> * Receipt of all previous messages and successful invocation of the
deliver
> operation.
> * The span of time indicated by the ExpiryTime element has expired.
>
> <JD> The first bullet is a repeat from the definition of Ordering, along
> with a way to
> implement it (persist messages). The second bullet is also a consequence
of
> our definition
> of Expiry time, obvious to an implementor.
> Finally, the REQUIRED above is too strong: memory constraints can also
> limit the persistence of such sequences.
> Finally, there are other ways to implement ordering, by relying on the
> persistence of the
> Sender instead of the Receiver: As Jun mentioned, there is a way to
> implement Ordering
> without persisting any pending out-of-order sequence, e.g. just by relying
> on the
> resending window to get messages in the right order. This may not allow
long
>
> out-of-order sequences, but this is an implementor's discretion to decide
> how much
> can be stored based on physical constraints.</JD>
>
> When supporting Duplicate Elimination, the receiver is REQUIRED to persist
> the
> Message Identifier until one of the following conditions are met:
> * The span of time indicated by the ExpiryTime element has expired
> * anything else?.
>
> <JD> again, this is implied by the definition of Duplicate Elimination,
> and the definition of Expirytime. We might as well make this a more
explicit
> and abstract
> requirement of Duplicate elimination: "when D.E. is required, the receiver
> RMP MUST
> check duplicates over all previous non-expired messages."
> Plus, this persistence requirement is
> somehow confusing, as for groups we don't need to actually persist every
ID
> but just remember intervals of seq nums.</JD>
>
>