OpenRTM-aist関連の皆様： 早大の菅です．
お世話になっております． 連続の投稿でご容赦ください．
LifeCycleStateの仕様について意見がありメールをしました．
現状では， ACTIVE，INACTIVE，CREATED，ERROR の4つの状態が定義されていますが， これだと論理的に矛盾する場合があるので，
「NOT_EXIST」（存在しない） とか 「DEAD」（死亡）
という状態が必要だと思います． 「ない」という状態が「ある」のか？ なんて難しい話になりそうですが， 自分が作っているツールだと 「ない」という状態が存在してしまいます．
実装上はLifeCycleStateをExecutionContextから取り出すので， そのownerであるRTCが見つからなければ， そもそもExecutionContextも見つからずに意味をなさないかもしれません．
ただ，矛盾なくシステムを設計するのに， 「存在しない」という状態が必要です．
現状はこちらで新しい状態群を定義して使っていますが， OpenRTM-aist側でもいずれ必要になる話と考えてメールをしました．
ご検討ください．
ではでは
モーションエディタ/シミュレータ
動力学シミュレータ
統合開発プラットフォーム
産総研が提供するRTC集
東京オープンソースロボティクス協会
ネットワーク分散環境でデータ収集用ソフトウェアを容易に構築するためのソフトウェア・フレームワーク
OpenRTM-aist関連の皆様：
早大の菅です．
お世話になっております．
連続の投稿でご容赦ください．
LifeCycleStateの仕様について意見がありメールをしました．
現状では，
ACTIVE，INACTIVE，CREATED，ERROR
の4つの状態が定義されていますが，
これだと論理的に矛盾する場合があるので，
「NOT_EXIST」（存在しない）
とか
「DEAD」（死亡）
という状態が必要だと思います．
「ない」という状態が「ある」のか？
なんて難しい話になりそうですが，
自分が作っているツールだと
「ない」という状態が存在してしまいます．
実装上はLifeCycleStateをExecutionContextから取り出すので，
そのownerであるRTCが見つからなければ，
そもそもExecutionContextも見つからずに意味をなさないかもしれません．
ただ，矛盾なくシステムを設計するのに，
「存在しない」という状態が必要です．
現状はこちらで新しい状態群を定義して使っていますが，
OpenRTM-aist側でもいずれ必要になる話と考えてメールをしました．
ご検討ください．
ではでは