[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] PR007: concrete proposal
Hi all, The text changes look ok to me, though I do wonder what the RMD is supposed to do with the TerminateSequenceResponse. If we assume that the RMD is going to maintain enough state to recognise the Seq Id in the TSR, then we do need to add a new column "Terminating" into the RMD state table. I think that the "Closing" column doesn't need to be added into the RMD state table. The only time we move into this state is the <CloseSequence autonomously> row, and I think we should move immediately into "Closed" state. That removes most of the blanks in the table. I think that there are 3 others, CloseSequenceResponse [msg] / Created state TerminateSequenceResponse [msg] / Created state TerminateSequenceResponse [msg] / Closed state I think it is correct to leave those blank, as the introduction to the table says: "A blank cell indicates that the behaviour is not described in this specification and does not indicate normal protocol operation. Implementations MAY generate a Sequence Terminated fault (see section 4.2) in these circumstances." which seems to apply here. I guess one purpose of the Closing column is to have a state where it is clear that we can resend close messages, but I think that can be expressed by making the <CloseSequence autonomously> / Closed state send a new CloseSequence message instead of the current N/A. Back to the possible "Terminating" state - I think it's unlikely that an RMD that has decided to terminate a sequence would ever want to retransmit the terminate, or do any work with the TerminateSequenceResponse, so adding a new column seems like a bit of a pain. However, if we do it then: "TerminateSequence autonomously" / Created and Closed states -> move to [Terminating] state Within the Terminating state: All inbound messages (except for the TSR) would generate UnknownSequenceFaults, an inbound TSR would move to [none] state. The only internal event that makes sense is "TerminateSequence autonomously", which would result in a new TerminateSequence message, and all other internal events are N/A. How does that sound? Matt "Gilbert Pilz" <gpilz@bea.com> wrote on 10/01/2007 00:58:15: > Attached is a new version of the proposal for PR007. As Doug > suggested I have updated the state tables to reflect the fact that > the RMD can send CloseSequence and TerminateSequence messages. I'm > not really happy with my changes to the state tables though. I added > a "Closing" state to the RMD table, but many of the cells are not > filled in. Also I am debating on whether or not to add a > "Terminating" state to the RMD table. I don't think it really needs > it, but I would like other peoples opinions. > > - gp > > p.s. Outside of Doug's comment, I haven't seen any discussion of > this proposal on the mailing list. If you wait until the concall to > read it and then have a lot of objections I will personally hunt you > down and . . . well I'm not sure what I'll do but it won't be pretty! >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]