RE: [bt-spec] Draft of model

[Peter Furniss <peter.furniss@choreology.com>]

Sanjay,

I've had this message blocked in my outbox for ages while the model went
through further internal mangling, but since yours were the only public
comments, they deserve a public answer.

I've included responses to your comments in the new draft, (with the user
identification "PRF for Sanjay", sd for the comments).  This is just about
the ones I where I haven't made a change or made a change that didn't agree
with what you said. Numbers are the comment numbers as they were in the
commented draft you sent.


4.  It's tricky sorting out which order to bring ideas in. I'm not sure one
wouldn't get into forward references if cohesion, atom comes in before 2
phase outcome. A cohesion does end up with a consistent decision for a
distributed set of things - it differs from the atom only in when and
exactly how it is determined what that set is.

5.  Had some difficulty getting a good phrase here. I think there were
several problems: participants may enrol at their own volition, not just by
invitation; we haven't defined participant yet (and the earlier text in the
bullets avoids it).   In fact, I don't think we want to worry about how the
parties got involved at this point. Several minor changes made in the
section to cope with this

6. Referred to the main example, and added a reference to another. The text
in this section had suffered from colliding editors :-)

7. Modified text and diagram

8. I don't think we want to discuss enrollment at this point. This is just
about inferior/superior, two-phase outcome etc. How things got put in place
is a detail for later.

19.  A Sub-coordinator will be atomic with respect to its inferiors, but may
be in inferior to Cohesion Composer (in fact this is the very common case of
a cohesion with a set of locally created atoms - those atoms are
Sub-coordinators, in Inferior:Superior relation to the Composer).  The
contrary case, of a node which has a cohesive relation to its own Inferiors
but is the Inferior of a atomic Superior, is also possible, if less common.
(The car hire company guarantees that they have got a car for you, but they
haven't actually decided which car it is).  A Superior can't tell what kind
of thing its Inferior is anyway.

20. Let a thousand flowers bloom :-)

23. Not advanced - this is the normal case for cohesion - atoms -----
participants.

28. added text in previous section

30. But the hazard is signalled to the Terminator by INFERIOR_STATUSES -
which allows for multiple hazards to be received and their origin
distinguished. The normative text on this was slightly garbled - Doug
Bunting pointed this out in his response to issue 50; now in as issue 107

31.  No, the text was right. Confirming the transaction isn't over until
CONFIRMED has been received from all the confirm set and CANCELLED or RESIGN
from all the other Inferiors - because you need to be sure the things that
weren't supposed to confirm didn't choose to do so on their own.

33. It better, hadn't it. Yes - INFERIOR_STATUSES entries include the
qualifiers from that inferior.

35. This optionality was something Ed Felt insisted on at the San Jose
meeting. Especially for the case of an inferior pestering a superior, the
receiver needs to have the right to ignore query until it has made a
decision. It's difficult to put this sort of configuration efficiency
information in a spec.

Thanks

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX