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側でもいずれ必要になる話と考えてメールをしました.
ご検討ください.
ではでは