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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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


Subject: RE: Sanjay's simplification


> I thought the idea of a vote changing on a subsequent PREPARE was
> to allow for the situation when the superior had performed
> further work on the atom with the subordinate after receiving a
> READY (possibly autonomously sent). The subordinate then must
> re-evaluate if READY is indeed the appropriate response...
>
> Of course if no further work has taken place on the atom since
> the previous PREPARE the answer should be the same. [Though as
> time has passed, is it *required* to be the same?]

Good point. But we (or some subset) discussed this around the time of the Mt
Laurel meeting, and concluded that view is really assuming the two sides
have a closer understanding of each other's working than is expected to be
the case - it violates the rule of thumb that the superior doesn't really
know what's going on inside the inferior: which participants are looking
after exactly which piece of application information and so on.

We concluded that if a service side had enrolled a participant, done some
work and then sent (voted) ready, and then received some more work, it
could:

a) if the new work could be done without trouble, add it to the
responsibilities of the original participant; or

b) enroll a new participant, and let that send ready or cancelled, depending
on what happened.

It would obviously be possible to try to slip the work into the old
participant and enroll the new one as a way of changing the result. (This
works fine if we can make the usual assumptions about not sending the
application reply back unless we are sure the enroll is going to work - hmm,
we've just found a case for compounding enrol+app_response+cancelled ( or
..+vote/cancel ) )

The alternative was a whole mass of stuff about un-prepare and so on, as the
superior needs to warn the inferior that it should open up the original
participant.


I don't think this ever got properly recorded in emails.


The suggested simplification seems to help a lot - I think we can probably
drop the distinction between spontaneous and prompted ready as well: ready
is ready is ready.

Peter



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


Powered by eList eXpress LLC