I
would try to avoid faulting such cases...
If we
push a proposal where any group-level semantics does not need be repeated in all
messages
but
only be determined unambiguously by - ideally - the first message of the group,
we
must handle the cases where the first ("start") message is lost,
or is not the first to be received.
We
could do:
- when
the group is "ordered" (and therefore acks are sent back) the Sender must
keep repeating
[identical] group info in each message until it receives first ack.
Receiver would take first received "group info" as the decisive
one.
Any
different or absent "group info" will be ignored by receiver after this.
- when group is unordered, and not even with guaranteed delivery,
the Ack can't be used.
Receiver still behaves like above:
if the
first , or few first messages of a group have not been received yet but say
message N is received first,
then
Receiver
would take first received "group info" (here in mesg(N)) as the
decisive one.
If none is there, Receiver would default on some
general parameter, e.g. for max duration of the group.
If no
group info and no parameter, in last resort, a fault would be sent back so the
Sender is reminded to insert group info
in its
next message (note that receiver can still correctly process previous
messages... group "attributes"
like
removeAfter do not need be known right away)
Nothing prevents of course a Sender to repeat "group info" in every
message. But even so, the spec should be clear as
how to
treat possible discrepancies or changes within a group.
In
spite of the elaborate "rules" above, I believe things would be much simpler
implementation-wise if we decide to treat
all messages of a group the same way
w/r to reliability features
(G.Ordering, DE, GD), as well as other parameters,
and that could be determined by what is in first
received message of the
group.
Jacques
-----Original Message-----
From: John Fuller
[mailto:]
Sent: Wednesday, October 15, 2003
5:57 AM
To: Jacques Durand
Cc:
''
Subject: Re: [wsrm] Rel
82
If the first received message in the group is not the "start" message do we
just fault then?
On Tuesday, October 14, 2003, at 07:57 PM, Jacques Durand wrote:
John: inline.
-----Original Message-----
From: John Fuller [mailto:]
Sent: Tuesday, October 14, 2003 4:25 PM
To: ''
Subject: [wsrm] Rel 82
82
The original document was difficult to work from as far as how
to deal
with conceivably different
values for the optional group removeAfter attribute for
messages in the
same group.
For example, most recent message's value could take
precedence, or the
maximum or minimum value
could win.
<JD> There is a more general issue that you raise here:
when the semantics
of some value (header element or attribute) is about the
entire group,
not just about the individual message that carries it, we only
need -in theory- to pick these values from the first message
of a group.
So a bold way to address the possible "contradiction" issue
across messages
of the same group is to pick the values of the first
message(s) of the group,
and ignore what the other messages say about it.
We have the case also with "MessageOrder" element: if it is in
the 1st
message of a group, I'd say the entire group is ordered...
regardless
of whether it is or not in following messages.
Any "dynamic" readjustment or exception within a group, would
be
confusing and make implemenations more complex.
Rel 57 clarified that the most recent timeout takes
precedence, though I don't believe
it's in the original specification.
<JD> I think the spec did not restrict what kind of
ExpiryTime
each messages of a same (ordered) group, should have/not, so
we
are allowed to consider any possible sequence of ExpiryTime
values.
(note this is a message-level value , not group-level, so
several
messages could not conflict with each other here).
We take the "earliest" of all ExpiryTime, which may come frm
any message
in the broken sequence...
Maximum idle time also seems legitimate, but it would be
helpful to
clarify which parameters
take precedence over which when in conflict, and explicitly
that the
last group values
overwrite previous assumptions, and if null values indicate
default to
service-level parameters
or default to previous parameters in the group if any?
<JD>, yes, we need to state some general rule for
group-level values.
I'd propose that unless we accept the trouble of allowing
group-level
parameters to change mid-way or have exceptions
(e.g. removeAfter be re-adjusted during a group),
the initial value is the good one.
I think it would be good to have service-level default
parameters/policies for cases where
the header doesn't contain the parameters.
<JD> Agree some "configuration" values/parameters should
have a standalone
existence, as it would be contrived to put them in headers
just to be able to
talk about them... Such parameters don't have to be described
as RMP parameters
(implementation level), but rather as part of the RM agreement
between two parties.
Even so, I believe we can keep referring to them in an
"abstract" way
(no need to come-up with an XML schema)
To unsubscribe from this mailing list (and be removed from the
roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
