Re: [bt-spec] BTP Issue 30 : Assume that coordinators are potentialsub-coordinators. (also issue 2)

[Mark Little <mark_little@hp.com>]

 

 

PF:  If the application isn't using the standard control interface to create and manipulate the coordinator, then it can certainly enrol later - the problem is how the Coordinator knows it has become a sub-coordinator, and we don't have a standard message to tell it. But a non-standard api certainly could.

 

Or were you thinking of the application enrolling a new sub-coordinator after the initial application work ?  which (this being the "implications" ? ), it can only safely do if it hasn't sent a CONTEXT_REPLY/ok, which surrenders it's right to do new enrollments.

 

("late enrollment" in the sense I used meant the enrollment of a btp entity as an inferior after it had already been created and had been able to respond to other operations (like accepting enrollments as a superior, sending prepare to it's inferiors etc), distinct from enrolling it as it is created)

Both. My question was really to flag this such that if we decide we want to allow it (and we can't really prevent it) then we should have some warning/caveat text in the spec. just to let users know what they are getting into.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250