中島様，末廣様，皆様：
早大の菅です．

Configurationに関して個人的な見解を申し上げたいと思い
メールを差し上げました．

長文・駄文で失礼します．

私個人の意見としましては，
Configurationの制約条件に，Inactive時の更新の許可・不許可を
加えるほうがよいと考えています．
また，変更時にフックが掛けられて，必要な処理を行える枠組みが
必要だと考えています．

この辺は，RTMを使って如何にシステムを組むか，
という設計論に近い部分があると思います．

以下，細かい話です．

私の場合，
DataPort　
→　RTC間のデータのやり取り
Configuration　
→　ツール側からのデータの送信
ServicePort　
→　InitやResetなどのデータのやり取りに縛られない処理．
　およびPull型のデータのやり取り

という住み分けになっています．
この前提での話をさせてください．

末廣様のおっしゃるように，Active状態中に制御パラメータを変更するのに，
ServicePortの機能を使うのは冗長だと思っていますが，
現状ではこれでも仕方ないと思っています．

私の場合では常時動的なパラメータ変更が行われる場合は，
独立したポートを作るか，独自型のIDLを使ったポートを作るか，
TimedOctetSeq型のポートを使って構造体を投げてしまいます．

これはRTC間の通信の場合です．

本来ConfigurationはSystem Editorのような汎用ツールでも変更できる
便利な機能ですので，ツール側から変更したい場合には，
中島様ご指摘の機能が必要だと思います．

ただ，末廣様ご指摘のように，Configurationの変更に対して，
必要な処理を行うべきという意見にも同意しています．

現状では，Configurationの変更をOnExecute内で監視しており，
変更された場合にInvalidなパラメータの場合は，
Error状態に移行する処置を行っていますが，スマートではありませんよね．

本来ならばConfiguration自体にフックをかけて，
変更があった場合にOnConfigured関数などが呼ばれるか，
フック用のオブジェクトを用意するのがよいと思うのですがいかがでしょうか．

現状のOpenRTMだと，
Configurationの変更時は
RTC::CorbaConsumer（実態はRTC::RTObject）
SDOPackageに直接アクセスしてしまっているので，
RTCでConfigurationというクラスを作って，
RTC::RTObject::get_configuration
では，RTC::Configurationが呼ばれるようにできませんか？
RTC::Configurationにフックがしかけられるようにするとよいと思います．

ではでは

Takashi Suehiro さんは書きました:
> 中島様、皆様、
>
> 末廣＠電通大です。
> この件に関して私は以下のように考えています。
> （以前も似た議論があったような気が、、、）
> あくまで個人的な見解です。
>
> パラメタを変更するときにConfigulationとServicePortとで
> 何が違うかということです。
>
> Yusuke Nakajima さんは書きました:
>> (1)RTCがINACTIVE時にのみ、変更＋反映可能なConfigulationパラメータ
> これが本来のConfigulationパラメタ。
>
>> (2)RTCがどの状態遷移にいても、変更＋反映可能なConfigulationパラメータ
> こちらは個別のサービスポートで対応するのが良い。
>
> つまり私は、
> ・Configulationの方は比較的汎用なRTCを起動時などに
> パラメタ設定するときに使う、
> ・動作中の動的な変更はServicePortで行う、
> のが良いと考えています。
>
> 動作中のパラメタ変更は多くの場合、変更が及ぼす影響を
> 十分に考慮して必要な処理も合わせて行う必要があります。
> 単純にパラメタだけ替えれば良いという場合は少ないと感じています。
>
> もちろん、そういう場合が多いということであればConfigulationで
> サポートするのも良いと思うのですが、そうでなければ
> 単純にしておいた方が良いと考えます。
>
> 他の方々のご意見も聞いてみたいと思っています。
> いかがでしょうか。
>
> よろしくお願いします。

皆様：
お世話になっております．早大の菅です．

すみません．先ほどのメールですが，
確認していくとCallbackはすでにあるようですね．

以下，細かい話です．

RTC::ConfigAdminクラスに，
onActivateSetなどのフック関数があり，
その中でRTC::OnActivateSetなどの
RTC::OnActivateSetインターフェースのオブジェクトが励起されるようです．

現状だと，RTObjectクラスのprotectedメンバで，
ConfigAdminクラスオブジェクトのm_configsetsがあるので，
これに対してsetOnActivateSetを使って上記の
RTC::OnActivateSetインターフェースを実装したオブジェクトをセットすれば
コールバックが実現されるようです．

ご参考まで．

Takashi Suehiro さんは書きました:
> 中島様、皆様、
>
> 末廣＠電通大です。
> この件に関して私は以下のように考えています。
> （以前も似た議論があったような気が、、、）
> あくまで個人的な見解です。
>
> パラメタを変更するときにConfigulationとServicePortとで
> 何が違うかということです。
>
> Yusuke Nakajima さんは書きました:
>> (1)RTCがINACTIVE時にのみ、変更＋反映可能なConfigulationパラメータ
> これが本来のConfigulationパラメタ。
>
>> (2)RTCがどの状態遷移にいても、変更＋反映可能なConfigulationパラメータ
> こちらは個別のサービスポートで対応するのが良い。
>
> つまり私は、
> ・Configulationの方は比較的汎用なRTCを起動時などに
> パラメタ設定するときに使う、
> ・動作中の動的な変更はServicePortで行う、
> のが良いと考えています。
>
> 動作中のパラメタ変更は多くの場合、変更が及ぼす影響を
> 十分に考慮して必要な処理も合わせて行う必要があります。
> 単純にパラメタだけ替えれば良いという場合は少ないと感じています。
>
> もちろん、そういう場合が多いということであればConfigulationで
> サポートするのも良いと思うのですが、そうでなければ
> 単純にしておいた方が良いと考えます。
>
> 他の方々のご意見も聞いてみたいと思っています。
> いかがでしょうか。
>
> よろしくお願いします。