RTC — Sequence diagrams for activation/deactivation should be added

everity: Support Text

Disposition: Resolution Proposed

Summary

I think it is difficult to understand behavior. I think it would be better that sequence diagrams is added.

Proposed Resolution

[attachment:rtc-activate-sequence.png] [[BR]] Activate

[attachment:rtc-activate-sequence2.png] [[BR]] Activate (Updated)

[attachment:rtc-deactivate-sequence2.png] [[BR]] Deactivate

Discussion

According to the update of the state machine diagram in FTF-2 issue, Activate sequence diagrams was updated.

– NoriakiAndo, 2006/12/4

Should callbacks be executed in the thread of the method that triggered the callback or in the thread of the execution context they refer to? For example, if I call myContext::activate_component(myComp) and the activation fails, should on_aborting be called in my calling thread or in the thread represented by myContext?

• Can the choice of thread be left to the implementation?
• Can the observed concurrency be left to the implementation? That is, if activate_component returns with a failure, can I assume that on_aborting has already been called?

I would propose that:

• The specification already says that the relationship between execution contexts and physical threads is implementation-defined. Therefore, components should not make any assumption about what thread they are called from. The callback argument identified the relevant context; that is the only important thing.
  *

The observed behavior of the callback should be synchronous with the method that resulted in the callback. For example, if I call activate_component, I can assume that on_activate will have finished before activate_component returns. This behavior simplifies error propagation and the programming model in general.

– RickWarren, 2006/12/4

Add the non-normative example diagrams as described below.