[printing-japan] BidiAPI 仕様書についてのコメント

[yoshida]

BBRの吉田です。

In message, Yasumasa TORATANI <toratani.yasumasa ＠ canon.co.jp>-san wrote on 
Mon, 08 Dec 2003 13:57:13 +0900...

> 虎谷です。
> 
> 色々ご指摘いただき、有難う御座います。
> 助かります。
> 
> On Fri, 05 Dec 2003 21:07:36 +0900
> yoshida <mikio-y ＠ zd6.so-net.ne.jp> wrote:

> > ・bidiGetCap の引数ですが、
> > 　capのenum指定に、以下の２つは必要ないですか？
> > 　BIDI_CAP_READ_SUMMARY 短縮形式のプリンタステータスデータのサポート
> 
> 今のところ、idReadModeに指定するモードは BIDI_READ_SUMMARYの
> １つしか考えていないのと、BIDI_READ_SUMMARYが OPTIONALである
> 訳ではないので、BIDI_CAP_READ_SUMMARYについては、現時点では
> 不要かと思います。
> 
> ＃現時点では常に、BIDI_CAP_READ_SUMMARYを指定します。
> ＃OPFCの実装では、BIDI_READ_SUMMARYだけで良いと思います。
> ＃で、弊社用の Bi-di Plug-inも、「一部」しか返していませんよね。
> 
> 今後、具体的にどのような read modeが必要か、検討していきたいと
> 考えています。

idReadModeについて、今想定しているモード以外にSUMMARY_MODEなるものが
あると勘違いしていました。現在、BIDI_READ_SUMMARYしかないということ
でここは理解しました。

> > ・bidiStartRead で
> > 　idReadMode に指定可能なモードは、BIDI_READ_SUMMARY のみになってい
> > 　ます。BIDI_READ_NORMALとか必要ないですか？
> 
> 上述でも述べましたが、今のところidReadModeに指定するモードは
> BIDI_READ_SUMMARYの１つしか考えていません。
> 
> 因みにBIDI_READ_NORMALとは、「完全なPrinter MIB XMLを返す」、の
> ような意味でしょうか？

上にも書いた私の勘違いで、今出力を想定しているモードとして、NORMALが
必要かなと思っただけです。

> > ・bidiCtrl
> > 　返り値に読み込んだデータのバイト数が設定されるように思うのですが？
> > 　もしそうだとすると、BIDI_OK はなしにして、BIDI_EINTRも必要になると
> > 　思います。
> 
> 確かにそうですね(^^;　で、思ったのですが、
> 1) Ctrlデータを送信時にシグナルを受信
> 2) Ctrlデータを受信時にシグナルを受信
> を、切り分ける必要があるでしょうか？

う〜ん、面倒な話ですね。
データの送受信を１つの処理と考え、切り分ける必要なしとしたいのですが、
シグナルが発生した場合、返り値に設定されるバイト数が、受信なのか送信
なのか区別が付かないですね。
1)と2)の０バイト受信にシグナル受信をまとめて、BIDI_EINTRにしませんか？

> > ・BIDI_CMD_NEW の記述３
> > 　bidiNewには、シグナルの受信により処理未完了のまま本関数から戻る場
> > 　合があるとありますが、caller側のBi-di APIでキャッチしたシグナルを
> > 　プロセスタイプのmoduleに渡す（killする）必要はありせんか？
> 
> その必要がありそうですね。
> 例えば、コマンドのシーケンスをリセットするためのシグナルだけが
> あれば良いでしょうか？

ハイ、それで構わないと思いますが。

> > ・BIDI_CMD_DESTROY 以降の記述
> > 　レスポンスに、BIDI_CMD_ERRORが使われてませんが、コマンドの書式が間
> > 　違っている場合など必要のように思えますがどうでしょうか？
> 
> 各々のシーケンスでコマンドパケットの正当性をチェックして、エラーなら
> BIDI_CMD_ERRORを返す、ということですね。
> 
> そのようなケースが発生した場合、Callerはそれ以降のシーケンスを
> 中断し、関数の戻り値としてBIDI_ERROR or NULLを返し、Bi-di Plug-in
> 側は、それ以降のシーケンスは中断されたものとみなす、
> のような処理になりますでしょうか？

ハイ。

> 因みに、関数自体のエラーは、Data=Return Value（例えばBIDI_ERROR）を
> 返すように定義してあるので、BIDI_CMD_ERRORを返すケースは
>  コマンドパケットが間違っている＝バグ or バージョン不整合という
> ことに限定されるかと思います。

ハイ。そう理解しています。

> > ・BIDI_CMD_STARTREAD の記述
> > 　シグナル処理について記述しないでよいですか？
> 
> これも、コマンドのシーケンスをリセットするためのシグナルだけが
> あれば良いでしょうか？
ハイ。

> > ・BIDI_CMD_READ の記述
> > 　Sequenceの2)で送出するバイト数を規定していますが、もし、
> > 　BIDI_CMD_WRITEと仕様を合わせるなら、この規定はカットしてもよいと思
> > 　いますがどうでしょうか？
> > 　ここでもシグナルの処理がいやらしいのですが、実際にread処理をしてい
> > 　る途中でシグナルが発生して、予定より少ないバイト数のデータを取得す
> > 　ることになるかもしれません。とすると実際に行ったread関数の返り値が
> > 　一番あてになると思うのですが。
> 
> 読み込み側は read関数の戻り値が一番あてになるのは正しいと
> 思いますが、書き込み側で既にそれ以上のデータを書き込んで
> しまっている場合、パイプに残ったデータはどうなりますでしょうか？
> ＃Caller側で掃除する or 再度読み込む必要はありませんか？

Caller側が次のタイミングで読みとかしないといけませんね。
前の仕様でよいと思います。

> > 　あわせて、シグナル処理についての記述も必要かと思います。
> 
> これも、コマンドのシーケンスをリセットするためのシグナルだけが
> あれば良いでしょうか？
ハイ。

> > ・BIDI_CMD_STARTWRITE の記述
> > 　シグナル処理についての記述も必要かと思います。
> > 
> > ・BIDI_CMD_WRITE の記述
> > 　シグナル処理についての記述も必要かと思います。
> 
> これも、コマンドのシーケンスをリセットするためのシグナルだけが
> あれば良いでしょうか？
ハイ。

> > ・BIDI_CMD_CTRL の記述
> > 　BIDI_CMD_READと同じ理由で、Sequenceの5)で送出するバイト数を規定し
> > 　ている部分はカットしてもよいのはと思っています。
> > 　あわせて、シグナル処理についての記述も必要かと思います。
> 
> これについても、読み込み側は read関数の戻り値が一番あてになるのは
> 正しいと思いますが、書き込み側で既にそれ以上のデータを書き込んで
> しまっている場合、パイプに残ったデータはどうなりますでしょうか？
こちらも前の仕様のままでよいと思います。

> あと、これもコマンドのシーケンスをリセットするためのシグナルだけが
> あれば良いでしょうか？
ハイ。

> 以上、よろしくお願いします。
> 
> -----------------------------------------
> Yasumasa TORATANI
> Computer Technology Development Dept. 12
> CANON INC. Shimomaruko Office, Japan

----
吉田　幹 　mikio-y ＠ zd6.so-net.ne.jp
(有)BBR