清水様
安藤です
Port周りに関しては、後付けでいろいろと機能をつけたしていった
関係で、いろいろ汚くなっているのですが、doilの導入やその他
いろいろ考えるところがあって、そのまま放置しています。
先ほどのメールにも書きましたが、RTCの基本的な考え方は、
仕様に基づきコンポーネントを設計し、ほとんどのコードをジェネレータ
で生成することで、実装するのが面倒でバグが入りやすいが、
大半は同じコードになうような、通信部分や状態遷移部分に関して、
バグの少ないプログラムを書けるようにすることで、コアロジック部分の
実装に集中できるようにすることを主眼においています。
ですので、Portを単体で使用したりすることは特に想定していません。
また、PortBase自体はRTObjectやPortAdminには依存して
なかったように思いますので、コンストラクタで暗黙のインスタンス化を
行っている以外は、単なるCORBAオブジェクトの実装であるように
思います。
余談ですが、PortBase自体はコンストラクタで_this()を呼んでいるので、
デフォルトPOAでactivateされてしまいますが、PortBaseが継承している
RefCountServantBaseを独自のRefCountServantBaseの派生クラスとし、
_default_POA() だったか、そのような関数をオーバーライドして、
希望のPOAを返すようにすれば、_this()で暗黙にactivateされる対象POA
をRootPOAではない任意のPOAに挿げ替えることはできます。
で、以前話題に上がったような気がするのですが、
サービスポートのサーバントが、RTCがInactiveの時に応答するのは
おかしいという意見がありまして、そのために今回1.0ではポートの
サービスインターフェースをRTCがInactive時にに非アクティブ化、
RTCがActiveの時にアクティブ化するように変更いたしました。
ただし、サービスポートを使用している方には申し訳ないのですが、
サービスポート同士を接続後にRTCをInactive状態にし、非アクティブ化
されたサービスポートのサーバントに、再度active化後にコンシューマから
アクセスしようとすると、IORが変わってしまっているのでアクセスできない
というかなり致命的な問題が発覚しました。
activate/deactivateを繰り返してもIORが変わらないようにするには、POA
のポリシーをPERSISTENTかつUSER_IDにしなくてはいけなかったのですが、
RootPOAをそのまま使用していたのが問題でした。
そういうわけですので、Portのみならず、CORBAオブジェクトの
POA周りの問題はRELEASEに向けて少々手を入れざるを得ない
状況ですので、清水さんのご指摘を参考に変更したいと思います。
ちなみに、上記のRTCの状態に応じてポートのサーバントが
非アクティブ・アクティブになるという仕様はどう思いますか？
相手がアクティブでないと、サービスが利用できないというのは、
ある場面では適当かもしれませんが、別の場面ではうっとうしい
だけのような気もします。
これについても、何かご意見をいただければと思います。
＃清水さんだけでなく、ほかの皆様にも。。。
では、
> OpenRTM-aist開発者の皆様
>
> Port関連の実装に関して気づいた点です。
>
> PortのCORBAオブジェクトは
> PortBaseクラスでimplicit activationされていますが、
> 同じクラス内でdeactivationされていません。
> なぜか、PortAdminクラスでdeactivateされています。
> （PortAdminで管理されない場合はどうするのでしょうか）
>
> オブジェクト指向的には、クラス単位で完結していることが
> 望ましいので、PortBaseでactivationしたのであれば、
> そのクラスでdeactivateもすべきと考えるのですが、
> どうでしょうか。
> （同じことは他のCOBRAオブジェクトにも言えます）
>
> これに関連するのですが、PortAdminの仕事の範囲は、
> (activate済みの）Portオブジェクトを管理するだけでなく、
> Portオブジェクトのactivate/deactivateまで
> もカバーする、という設計でしょうか。
> （その場合でも、Portオブジェクトのactivate処理
> はないので、完備性の観点からは問題があると思いますが）
> 私としては、PortAdminクラスは、
> activate済みのPortオブジェクトを管理するだけに
> 絞った方がわかりやすいと感じます。
>
> 上述のPortオブジェクトのactivate/deactivate管理の
> 役割分担があいまいなために、RTObjectでのPortの操作も
> わかりにくいと感じました。
> 具体的には、Data PortをRTCに登録するときは、
> registerInPort/registerOutPortを呼ぶのに、
> この逆の操作はdeletePortとなっている点です。
> unregiterInPort/unregisterOutPortの方が
> わかりやすいのではないでしょうか。
>
> さらに、PortをRTCに登録する場合は
> Portオブジェクトはactivationされないのに、
> 登録解除の際は自動的にdeactivateされてしまうのは、
> ユーザからはわかりにくいし不便な場合もあるかと思います。
> （稀なケースとは思いますが、Portオブジェクトを
> 他のRTCに移譲する場合とか。）
> また、確か、RTC仕様上はPortオブジェクト単独で存在する
> ことも可能だったと思うので、RTCまたはPortAdminに
> 依存する現在のPort実装は少し問題があるのではと感じます。
>
> 以上、気づいた点です。
> ご検討頂ければ幸いです。
>
> 静岡大 清水
OpenRTM-aist開発者の皆様
Port関連の実装に関して気づいた点です。
PortのCORBAオブジェクトは
PortBaseクラスでimplicit activationされていますが、
同じクラス内でdeactivationされていません。
なぜか、PortAdminクラスでdeactivateされています。
（PortAdminで管理されない場合はどうするのでしょうか）
オブジェクト指向的には、クラス単位で完結していることが
望ましいので、PortBaseでactivationしたのであれば、
そのクラスでdeactivateもすべきと考えるのですが、
どうでしょうか。
（同じことは他のCOBRAオブジェクトにも言えます）
これに関連するのですが、PortAdminの仕事の範囲は、
(activate済みの）Portオブジェクトを管理するだけでなく、
Portオブジェクトのactivate/deactivateまで
もカバーする、という設計でしょうか。
（その場合でも、Portオブジェクトのactivate処理
はないので、完備性の観点からは問題があると思いますが）
私としては、PortAdminクラスは、
activate済みのPortオブジェクトを管理するだけに
絞った方がわかりやすいと感じます。
上述のPortオブジェクトのactivate/deactivate管理の
役割分担があいまいなために、RTObjectでのPortの操作も
わかりにくいと感じました。
具体的には、Data PortをRTCに登録するときは、
registerInPort/registerOutPortを呼ぶのに、
この逆の操作はdeletePortとなっている点です。
unregiterInPort/unregisterOutPortの方が
わかりやすいのではないでしょうか。
さらに、PortをRTCに登録する場合は
Portオブジェクトはactivationされないのに、
登録解除の際は自動的にdeactivateされてしまうのは、
ユーザからはわかりにくいし不便な場合もあるかと思います。
（稀なケースとは思いますが、Portオブジェクトを
他のRTCに移譲する場合とか。）
また、確か、RTC仕様上はPortオブジェクト単独で存在する
ことも可能だったと思うので、RTCまたはPortAdminに
依存する現在のPort実装は少し問題があるのではと感じます。
以上、気づいた点です。
ご検討頂ければ幸いです。
静岡大 清水