Issue 10490: Inconsistent definition of LifeCycle::reset                                                                                                                                                             (rtc-ftf)
Source: Technologic Arts (Mr. Takeshi Sakamoto, tsakamoto@tech-arts.co.jp)
Nature: Uncategorized Issue
Severity: 
Summary: ource: Technologic Arts (Takeshi Sakamoto, [[MailTo(tsakamoto AT SPAMFREE tech-arts DOT co DOT jp)]])

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the definition of !LifeCycle::reset?

reset(ExecutionContext) : ReturnCode_t

...as in Figure 7.2 (Page 11) and Table (Page 15)

Or:

reset() : ReturnCode_t

...as in RTC IDL (Page 75) and mars/2006-09-34 (Example C++ header)

Discussion

Resetting is relative to a particular execution context (see the lifecycle state machine), so I think it has to be the former:

reset(ExecutionContext) : ReturnCode_t

-- RickWarren, 2006/11/27

Resolution

There has been a suggestion to move reset to ExecutionContext to make it similar to activate_component, deactivate_component, and get_component_state. The new operation would be called reset_component. The ExecutionContext would therefore be a kind of "manager" for the component's per-context state. -- RickWarren, 2006/12/1

Revised Text
Resolution: Resetting a component is relative to a given execution context. This behavior should be mediated by the context, just like component activation/deactivation. Move the reset operation to ExecutionContextOperations as reset_component.
Revised Text: ·	In figure 7.2, Lightweight RTC Package, in section 7.2.2, Components, remove the reset operation from LifeCycle. Add the operation "reset_component(LightweightRTObject) : ReturnCode_t" to ExecutionContextOperations. (The latter was added to figure 7.3 by the resolution to issue 10601.)
·	In figure 7.4, RTC lifecycle, in section 7.2.2.3, LifeCycle, replace the trigger LifeCycle::reset with ExecutionContextOperations::reset_component.
·	Remove the "reset" row from the operations table in section 7.2.2.3, LifeCycle.
·	Move section 7.2.2.3.4, reset, immediately after 7.2.2.6.7, deactivate_component, and rename it to "reset_component".
·	In RTC.idl and in Annex A, remove the operation LifeCycle::reset. Add the following operation:
interface ExecutionContext {
    // … (after deactivate_component)
    ReturnCode_t reset_component(in LightweightRTObject comp);
    // …
};

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

End of Annotations:=====
MG issue 10490: Inconsistent definition of LifeCycle::reset

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

Severity: Minor

Disposition: Resolution Proposed

Summary

Which is correct as for the definition of !LifeCycle::reset?

reset(ExecutionContext) : ReturnCode_t

...as in Figure 7.2 (Page 11) and Table (Page 15)

Or:

reset() : ReturnCode_t

...as in RTC IDL (Page 75) and mars/2006-09-34 (Example C++ header)

Discussion

Resetting is relative to a particular execution context (see the lifecycle state machine), so I think it has to be the former:

reset(ExecutionContext) : ReturnCode_t

-- RickWarren, 2006/11/27

Resolution

There has been a suggestion to move reset to ExecutionContext to make it similar to activate_component, deactivate_component, and get_component_state. The new operation would be called reset_component. The ExecutionContext would therefore be a kind of "manager" for the component's per-context state. -- RickWarren, 2006/12/1

Revised Text