[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Proposed resolution for Rel 50
Sunil:
My next action will be to revise Rel52, 57 based on this. Some more inline comments, though.
-----Original
Message----- Jacques Durand wrote: Sunil: I have been thinking about the two proposed semantics for ExpiryTime, and I do not see them as different as I thought initially. That was
my point all along. But there is more to fix even if we keep previous semantics: the "processing model" we had outlined in last f-2-f Wednesday minutes, 6.2 Rel50) does not hold anymore, w/r to Acks: If you don't require an up-front expiration check, that means you will Ack positively an expired message, then later send an Error for non-delivery to app due to expiration. I must admit yours is also the original one as currently worded in the spec.Although I Yes. I'm not proposing anything new. Just want the current semantics to stand. believe the current semantics adds unnecessary checks and cases, and pretends to an "application Only thing
would be one additional "timestamp" stamp. This is a drop in the ocean
especially we [Jacques Durand] If we keep it as is, one more rule now for not delivering an Acked message, is that if it expires. Agree group termination does not seem to be affected much one way or the other. (This was the point I was making at the F2F.. which no one seems to caring :))
semantics" flavor that is no substitute tobusiness-level timeout handling in the application in my view, I can settle with this. The inconsistencies you still see in my proposal (your scenario case), however, I contend only occur if you authorize the Sender to bump-up ExpiryTime whenresending a message, which I still strongly oppose (and the current spec is on myside on this, see 3.1.4 in V0.7). Indeed, I believe this ExpiryTime update does not have any semantic ground, and introduces all sorts of complications, from dup elimination to group expiration management. I believe
I can clarify the semantics very clearly without any confusion. However as I
said in my [Jacques Durand] I’d prefer to keep ExpiryTime immutable, once it is set… (so all in all, we keep as much of the current spec as we can :) I thought
of another discrepancy with this model, but I don't seem to recollect right
now. The ExpiryTime as defined currently seems to now reflect an app to app contract, and has no reason to see its value upgraded for a given message, I believe, due to underlying transport/RMP mishaps. Would you agree with this analysis? Yes, but that will have a bearing on RMP implementation for persistence and DE. [Jacques Durand] And I think this bearing is positive, but let us postpone this debate :) I propose to adjust my proposals of Rel52, Rel50, Rel57 to rally thecurrent (yours) definition of ExpiryTime, so that we can move on. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]