安藤様

静岡大の清水です。

実装レベルまでの詳細な説明ありがとうございます。
いくつか気になった点があるので質問させてください。

> [ノード（ホスト）名]/[カテゴリ名]/[RTC型名]/[インスタ
ンス名]

この命名法は一意であるとしていますが、
ノード名の一意性は確実に保証されるのでしょうか？
ノード名としてホスト名（human readableなので）を
用いる場合、ホスト名はユーザが勝手に決められるので、
かぶる可能性があります。

実際、Linuxの場合、ホスト名をデフォルトの
localhostのままでネットワークに参加できる
（IPはネットワーク内で一意なので）ため、
複数マシンがlocalhostノード名を
持つことになると思います。
こういった場合はどう対応するのでしょうか？

> ＃ネームサーバに登録済みコンポーネント名から、次に生成
するRTCのインスタンス名を決める
> ＃たとえば、すでに MyComponent0, MyComponent1, ...,
> MyComponentNがネームサーバ上に登録されて
> ＃いるのであれば、次のコンポーネントの名前は
> MyComponent(N+1) のようになる。

RTCのインスタンスごとにどのネームサーバに登録
するかをconfで決められるようになっているので、
たとえば、一つ目のインスタンスはServer1のみに登録し、
二つ目のインスタンスはServer1とServer2に登録する場合、
Server1ではMyComp0とMyComp1が存在しますが、
Server2ではMyComp0のみになります。
ここで問題なのは、Server1のMyComp0と
Server2のMyComp0が違うオブジェクトになることです。

ネームサーバ上の名前を見ながらオブジェクトを
操作するのは人間であることが多いので、
サーバによって名前が違ったり、
同じ名前だけど実態は違うといった状態になると
ユーザが混乱しないでしょうか？
私としては、違うサーバでも同じ名前で
あって欲しいと考えるのですが、
安藤様はいかがお考えでしょうか？

以上、ご意見をお聞かせ頂ければ幸いです。

清水

安藤様，清水様，末廣様：
早稲田の菅です．

いろいろとご指導ありがとうございました．

＞末廣様の投稿[739]より
> ・上書きする、
> ・自動的に連番を振る、
> ・失敗する、
> のどれが本当のところ使いやすいか
> と考えた場合、私は３番目だろうと思っています。
> さらに、なぜ失敗したかの情報も分かるとより嬉しい。

なるほど．
僕はcreateComponentの引数によって上記3つが選べる仕様がよいと思います．
僕自身の使用感だと，デフォルトで2番が使いやすいと思いました．

この点で，安藤様の実装方法に関する投稿[740]の中で，
> registerFactory(Properties, NewFunc, DeleteFunc, NumberingPolicy)
> {
> 　：
> 　m_factory.list.push_back(new FactoryCXX(property,
> newfunc, delfunc, policy))
> 　：
> }
> のようにpolicyを渡せるようにした上で、
> 各コンポーネントのナントカInit()関数内の
> registerFactoryの呼び出しで、独自のNumberingPolicyを渡してあげれば、
> 任意の命名方法を与えることができます。

との実装でうまくいきそうですよね．
次期ミドルウェアではregisterFactoryの
4番目の引数の開放があるとよいと思います．
デフォルトは今のままでもミドルウェアの再コンパイル無しに
カスタマイズしたNumberingPolicyが指定できるといいですよね．

NumberingPolicyの実装方法についても
丁寧にご説明くださりありがとうございました．
時間があるときに自分で実装してみるつもりです．

ではでは

Ando Noriaki さんは書きました:
> 安藤です
>
> 続き（実装について）です
>
> 実は、0.4.0にはAPIとしてユーザには解放されていませんが、
> コンポーネントの名前付けのポリシーを変えられる仕組みが用意されています。
>
> これは、コンポーネントのFactoryクラスです。
> http://www.is.aist.go.jp/rt/OpenRTM-aist/doxygen/ClassReference/classRTC_1_1FactoryCXX.html
>
> コンストラクタの最後の引数に NumberingPolicy が渡されていますが、
> これがインスタンスの名前付けの方法を決めています。
> デフォルトでは DefaultNumberingPolicy オブジェクトが渡されますが、
> 別のPolicyオブジェクトを渡すと任意の名前の付け方に変更することができます。
>
> ただし、現在の0.4.0では
> http://www.is.aist.go.jp/rt/OpenRTM-aist/doxygen/ClassReference/classRTC_1_1Manager.html#09c70d1b01c1f1969abe64d928c435ee
>
> のregisterFactoryの引数にNumberingPolicyがないのを見てもお分かりいただけるように
> Policyを変更するすべはありません。
>
> 今、手元にソースがないので嘘を書いているかも知れませんが、registerFactory関数はたぶん中で、
>
> registerFactory(....)
> {
> 　：
> 　// Factoryのリストに新しいファクトリを登録する
> 　m_factory_list.push_back(new FactoryCXX(property, newfunc, delfunc))
> 　：
> }
>
> のようになっているのではないかと思いますが、これを
>
> registerFactory(Properties, NewFunc, DeleteFunc, NumberingPolicy)
> {
> 　：
> 　m_factory.list.push_back(new FactoryCXX(property, newfunc, delfunc, policy))
> 　：
> }
> のようにpolicyを渡せるようにした上で、各コンポーネントのナントカInit()関数内の
> registerFactoryの呼び出しで、独自のNumberingPolicyを渡してあげれば、
> 任意の命名方法を与えることができます。
>
>
> NumberingPolicyの具体的な実装方法ですが、
>
> http://www.is.aist.go.jp/rt/OpenRTM-aist/doxygen/ClassReference/classNumberingPolicy.html
>
> のNumberingPolicyクラスを継承して、onCreate (void *obj)関数を実装するだけです。
> 先ほどのメールで提案した、以下の2種類の命名方法を実現する方法を書きます。
>
> 1． [ノード（ホスト）名]/[カテゴリ名]/[RTC型名]/[インスタンス名]
>
> std::string onCreate(void* obj)
> {
> names = 同一マシン上の他のマネージャ上でインスタンス化されている
> 　　　　　　　同一カテゴリ・型名のインスタンス名を取得
> namesから当該RTCの次のインスタンス名を計算
>
> return 新しいRTCのインスタンス名;
> }
>
> このようになると思います。
> ここで、「同一マシン上の他のマネージャ上のインスタンス名」を取得するのが
> 現状では難しいです。同一マシン別プロセスのマネージャ同士が、どういう
> RTCのインスタンスを持っているかの情報を交換できる必要があります。
> 今のところそのようなことはできませんが、1.0では少なくとも同一ノード上の
> のマネージャ同士がこれらの情報を共有できるようにはするつもりです。
>
> この方法は、同一ノード上で一意なナンバリングをするだけでよいので、
> Managerを少々拡張するだけで実現可能です。
>
> 2．[カテゴリ名]/[RTC型名]/[インスタンス名]
>
> std::string onCreate(void* obj)
> {
> typename = obj->getTypeName(); //とりあえずベースとなる型名を取得
> nmformats = Manager::instaqnce().getConfig()["naming.formats"]; //
> 名前付けのフォーマットを取得
> nss = Manager::instaqnce().getConfig()["corba.name_servers; // ネームサーバ名を取得
>
> for (各ネームサーバ毎に) {
> # 当該 [ノード（ホスト）名]/[カテゴリ名]/[RTC型名]/[インスタンス名] で登録されている名前を取得
> }
> ＃ネームサーバに登録済みコンポーネント名から、次に生成するRTCのインスタンス名を決める
> ＃たとえば、すでに MyComponent0, MyComponent1, ..., MyComponentNがネームサーバ上に登録されて
> ＃いるのであれば、次のコンポーネントの名前は MyComponent(N+1) のようになる。
>
> return "MyComnponent(N+1)";
> }
>
> 以上、こんな感じで実装すれば、菅さんがご希望の名前付けが実現できるのですが、
> 0.4.0のときにはそこまでやる余裕がなかったので、DefaultNumberingPolicyのみとなっています。
>
> 最後の末廣さんのメールにもありましたように、OpenRTM-aistに
> あまりたくさん機能を詰め込まないほうがいいというのも同意です。
> 最近、OpenRTMをuITRONに移植したのですが、uITRONでRTCを
> 動かしたいようなターゲットは、上記のような複雑な名前付けをさせるのは
> メモリ的にも、CPUパワー的にもしんどそうです。
>
> 安藤個人の意見としては、各コンポーネントの*Init()内でPolicyを渡すのではなく、
> いくつかのタイプのNumberingPolicyをあらかじめ用意しておいて、
> （かつ、それがDLLでローダブルだともっといいかも。）
> confファイルから各コンポーネント毎に適当なNumberingPolicyを指定する
> というやり方が良いのではないかと考えています。
>
> これなら、菅案、清水案、末廣案にも何とか対応できるでしょうし、
> 将来的に別のユースケースが現れた時にも対応可能です。
>
> いかがでしょうか。