Issue 10479: Sequence diagrams for activation/deactivation should be added                                                                                                                                           (rtc-ftf)
Source: Technologic Arts (Mr. Takeshi Sakamoto, tsakamoto@tech-arts.co.jp)
Nature: Uncategorized Issue
Severity: Minor
Summary: 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
Resolution: Add the non-normative example diagrams as described below.
Revised Text: ·	In section 7.2.2.6.6, activate_component, the following sentences and diagrams should be added after the "Description" subsection.
SemanticsThe following figure is a non-normative example sequence diagram for activate_component.  Figure 7.8 - ExecutionContextOperations::activate_component
·	In section 7.2.2.6.7, deactivate_component, the following sentences and diagrams should be added after the "Description" subsection.
SemanticsThe following figure is a non-normative example sequence diagram for deactivate_component().  Figure 7.9 - ExecutionContextOperations::deactivate_component

Actions taken:
December 5, 2006: received issue
January 15, 2008: closed issue
Discussion: 

End of Annotations:=====
MG issue10479: Sequence diagrams for activation/deactivation should be added

Source: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: 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