[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] Draft of model
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC