返信のテストです。
コミュニケーション知能コンポーネント共通インターフェースに関する議論
文字列型をTimedStringを使うのはどうでしょう.マルチバイト文字の場合,エンコーディング,エンディアンなどもろもろの問題があって,Stringのみだとすごく使いずらいです.かといってWString型でも非力だと思います.新しいバージョンは確認していませんが,以前のバージョンだと,上記の問題で苦労しました.文字列専用ポートに,エンコーディングやエンディアンの自動変換機能があるべきだと思いますがどうですか?
今の規格ではTimedStringを使うということになっています。
文字列については、実は規格の第1版が決まる直前までTimedWString型にしようと議論していたのですが、土壇場でTimedStringに変更したという経緯があります。
[Timed]WStringを使うとCORBAが自動でエンコーディングを変換してくれるのですが、この機能はCORBAの最近の規格に対応していないと使うことができません(omniORBには完全に実装されていますが、CORBAの実装によってまだばらつきがあるようです)。
またエンコーディングの自動変換機能をミドルウェア側に持たせてしまうと、ミドルウェア側が重くなってしまうという問題もあります。コミュニケーション知能としては欲しい機能ではありますが、例えばモータ制御コンポーネントなどを使う人達が使わない機能でメモリフットプリントが大きくなってしまうというのは申し訳ない、、、や、軽量のCORBA実装なども試みられている中でエンコーディングの自動変換も実装してくれ、というのはかなり大変そう、、、という理由で、変換が必要であればコンポーネント側にその機能を持たせようという判断を現状ではしています。
エンコーディングに関する一応のルールとしては、
・国際化文字列は基本はUTF-8を使う
・TimedStringの中にはXMLデータを書いても良い、その場合はencodingタグでエンコーディングを指定しても良い
となっています。
エンディアンの自動変換に関してはミドルウェアレベルで既に実装されていると思っていたのですが、どうでしょうか?
土壇場で上記のような決め方をしたのは良いものの、C++とPythonに関してはString型からWString型へのキャストが容易にできるものの、Javaでは結構難しいという話も聞きます。
それも含めて良い落とし所はないものでしょうか?
Javaでキャストする例も作ってみました(SimpleIOを改造しています)。
汚いですね、、、。 この程度の処理であればミドルウェアの重さには関係ないので、ミドルウェア側に取り込ませて隠蔽してしまっても良さそうですね。
叩き台としての第1版はこちらにあります。 コミュニケーション知能コンポーネント規格(第1版)http://www.openrtm.org/OpenRTM-aist/documents/IRT_PJ/irt-spec-communication-ver1.pdf
拡張・改良について話し合いましょう。
まだ未解決の問題(一部):
・データ型が全てTimedOctetSeqなので、音声信号のフォーマットが違ってもリンクが繋がってしまう。
・構文解析などの言語処理の部分の規格(XMLへの追加アノテーション)をどうする?
・対話マネージャ用スクリプトのフォーマットを揃えることは可能か?
・サービスポートは作らないで良いのでしょうか?
などなど、ご意見お待ちしています。