RE: Open-top coordinators and protocol

[Savas Parastatidis <savas@arjuna.com>]

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.