[printing-japan] Bi-di資料

[Yasumasa TORATANI]

虎谷です。

On Thu, 04 Dec 2003 14:33:42 +0900
Masaki IWATA <iwata ＠ axe-inc.co.jp> wrote:

> アックスの岩田です。
> 
> 虎谷 樣
> 
> Bi-di API のことでお尋ね致します。
> まだ、根本的な理解が不足しておりますので、間抜けなことも
> 訊いてしまうと思いますが、お許し下さい。

いえいえ。
抜けを指摘して頂けると有り難いです。
宜しくお願い致します。

> また、既に議論されている内容がございましたら、過去ログの
> 参照箇所を教えて頂ければ幸いです。

この辺りは、以前のミーティングで議論したことなので、ログには
残ってないかもしれません。

逆に以前のミーティングで話したことと違っていたら、指摘して
もらえると助かります　＞皆様

> --
> 
> bidiNew() には、引数にプリンタポートの fd が含まれていない
> ようなのですが、どのように制御されるのでしょうか?

プリンタポートは、Bi-di Plug-inの呼び元がオープンして、
bidiNew関数の引数として渡します。
通常の場合、fdRead == fdWriteとなりますが、それらが異なる場合も
想定して、２つのfdをbidiNew関数に渡すようにしています。

> BiDiC 型の定義の記述が見当たらないのですが、実装依存という
> ことでしょうか?

はい。実装依存です。

> また、BiDiC 型はポインタでしょうか?
>   BiDiC bidiNew(...);
> という定義と、
>   void bidiDestroy(BiDiC *pBiDiC);
> という利用法に、若干とまどっております。

すみません。誤記です。
   BiDiC *bidiNew(...);
が正しいです。修正します。

> bidiNew() で指定する fdRead,fdWrite と、bidiGetReadFD(),
> bidiGetWriteFD() で取得する fd の関係は、どのようになって
> いるのでしょうか?

共有ライブラリ型の Bi-di Plug-in module を bidiNewで指定する場合
bidiNewで与える fdRead,  fdWrite は、bidiGetReadFD, bitiGetWriteFD
関数で取得される fd と同じになります。

一方、プロセス型の Bi-di Plug-in moduleを bidiNewで指定する場合
bidiNewで与える fdRead, fdWrite は、Bi-di Plug-inプロセスに引き
継がれ、さらにBi-di Plug-inプロセスと呼び元のプロセスの間に
４つのパイプが構築されます。そのパイプの呼び元側のデータ転送用の
fd が、bidiGetReadFDと bidiGetWriteFD関数で返ることになります。

> bidiGetReadFD() によって取得する fd によってデータを受け取
> る場合と、bidiStartRead(),bidiRead(),bidiEndRead() コマンド
> 群を利用する場合の相関関係はどのようになっているのでしょう?
> 併用/同時使用は可能なのでしょうか?
> また、fd を利用する場合も、bidiStartRead(),bidiEndRead() を
> 発行する必要があるということでしょうか?
> 
> Write 系も同様でしょうか?

併用は可能と言えば可能です。

例えば共有ライブラリ型の Bi-di Plug-inの場合、bidiGetReadFDから
取得した fd から直接データをリードすると、プリンタからの生の
ステータスデータを取得できるでしょう。
一方、bidiRead関数を通した場合は、Printer MIB XML形式で
ステータス情報が呼び元に返ります。

しかし、プリンタから生のステータスをreadした後、bidiRead関数を
用いてステータスをreadする際に、正しくステータスが読み込めるか
否かは、実装依存になると思います。

そのような意味で、bidiGetReadFDや、bidiGetWriteFDによって
取得された fd を直接使うのは、好ましくないでしょう。それらの fd は
select による処理の分岐だけに用いるのが良いと思います。

> また、process タイプの場合
> 
> コマンドラインオプションの説明で、
>   ・これらのパイプは、Bi-di Plug-in module process の起動に
>     先だって呼び元によって生成されなければならない。
>   ・呼び元は Data Reading Pipe の file descripter を bidiGe-
>     tReadFD 関数で、Data Writing Pipe の dile descripter を
>     bidiGetWriteFD 関数で取得する。
> とありますが、これも相関関係が掴めません。

呼び元は、プロセス型の Bi-di Plug-inをforkする前に、それと
通信するための４つのパイプを生成して、Bi-di Plug-in moduleを
execする際に、生成したディスクリプタの値を引数で渡し、呼び元
には、bidiGetReadFD, bidiGetWriteFDによって、Data Reading Pipe
と Data Writing Pipe のfdを返す、ということです。
（ラッパーが返します）

> コマンド送受のパイプの説明で、
>   ・Command Writing Pipe および Command Reading Pipe は呼び
>     元からは直接は参照されず、Bi-di Plug-in API の内部処理
>     において利用される。
> という文章の意図するものがよく解らないのですが、これは、ラッ
> パーが処理するから意識する必要がない、という意味でしょうか?
> ( process タイプ Bi-di 用のラッパーもあるのですよね?)

そのとおりです。

> ところで、ジョブのキャンセル処理なのですが、bidiCancelJob()
> は、CUPS からのキャンセル指示のためにあるものだと思うのです
> が、これをプリンタステータスユーティリティからも指示できる
> ようにするというような予定があるのでしょうか?

CUPSからということは、Type Aですよね。

CUPS からジョブのキャンセルが発行されると、backendには
SIGTERMが発行されます。backendは、SIGTERMを受信したら
ジョブのキャンセル処理を実行するようにします。

ジョブのキャンセル処理では、bidiCancelJob、bidiEndJob, 
bidiDestroyが呼ばれなければなりません。

-----------------------------------------
Yasumasa TORATANI
Computer Technology Development Dept. 12
CANON INC. Shimomaruko Office, Japan