So, we propose that answer 1) is chosen. A
Coordinator, once created by BEGIN (no CONTEXT) will be a Decider.
Sub-coordinator's are created with BEGIN & CONTEXT.. There is no "late
enrollment".- sub-coordinator knows who its Superior is from the
beginning.
This is fine by us, but are we still letting the
application enrol later? If so, we probably need to put something in the spec.
as to what the implications of this are.
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)
Peter