[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Open-top coordinators and protocol
Peter, Please refer to my reply to Alastair for my most recent comments on the discussion. Only a very few comments on this message. [... deleted ...] > > If my understanding of Alastair's proposal is correct, the > > sendApplicationMessage() and prepare() calls should be replaced with a > > sendApplicationMessageAndAllowPrepare() single call. This will result to > > Not quite - you still need the prepare() (or equivalent) on the atom > coordinator, to induce the coordinator to report on the combined vote for > the whole atom. > Yeap. I agree. > > There is then a separate question as to whether the indication that the > messages are complete should be in a BTP-defined construct or left to the > application. This is hard to give a firm answer on, but I inclinde to a > BTP-defined construct. This makes it easy to BTP-ise an application > exchange > that does not itself have the concept of packaging its requests into > groups, > without requiring additions to the application messages in an ad-hoc > manner. I am tempted to move the responsibility for such optimisations to the application level rather than adding to the protocol level. Please, refer to my previous message for more details. > (arguably an application X + BTP isn't quite the same protocol as X alone > and doing so does add messages (the btp allow-vote) to the application > messages, but the advantage is that you can do exactly the same thing for > Y+BTP, Z+BTP etc). A midway position is to have a BTP-defined > "allow-prepare" but also permit voting at any point (used with different > applications) - this is truly implicit prepare, but if a > service+participant > believes it can vote, who are we to say it doesn't understand the > application protocol. > We are not in disagreement on whether an implicit prepare is allowed but rather who is responsible for its initiation. I disagree that we should have an allow-prepare at the BTP-level. Again, refer to my previous message to Alastair. > atoms, if it needs to know distinctly "will this operation really work", > it > should ask the atom that includes it. It won't help it to know that the > first involved participant is ok, if there is another (directly > registered) > participant it can't see lower down that will cause the operation to > cancel. > Agreed. (I like this word :-) Regards, .savas.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC