[printing-japan] Question about requirements for PCM
Ide Kentaro
Ide.Kentaro @ exc.epson.co.jp
2005年 1月 18日 (火) 08:40:30 PST
井手です
あぁっ、そうでした。本年もよろしくお願いいたします。
| サンアントニオでの議論で、Glen曰く、
| 1) 「OpenPrintingのアーキテクチャにおいて、全てのモジュールは、
| 必ずPCMを通じてデバイスやネットワークと通信する」
| という要求事項とともに、
| 2) USBのような低レベルなI/Oも、IPPのような高レベルなネットワーク
| プロトコルも、PCMを介して同等に扱うことができるようにする。
| を要求事項としました。
|
| 1)と2)を同時に満たそうとすると、
| 例えば、
| 「IPPを使ってジョブ管理をするアプリケーション」
これは、果たして、”OpenPrintingのアーキテクチャ”における"全てのモジュール"に
該当するものなんでしょうか?
IPPを使ってジョブ管理をするアプリケーションAとOpenPrintingアーキテクチャな
印刷フレームワークBと、IPPなプリンタCが存在する場合、
・AはCに直接接続を行う
・AはBを経由してCに接続する
のいずれなんでしょう?
前者のほうが自然に感じます。
私には、Glenが言っている"全てのモジュール"が指しているのは、
OpenPrintingのモジュールであって、その上のアプリではない。
また、OpenPrintingフレームワークが考慮すべきなのはPAPIを使って
プリントを行おうとしているアプリだけ。…であると取れるのですけど、
どうなんでしょうね。
#同様のなげかけ&議論を英語でもすべきかなぁ
| 逆に、PCMが「Job一覧を取得する機能」を用意しない場合、
| 「IPPを使ってジョブ管理をするアプリケーション」は、PCMを使って実装
| することができなくなります。
この点も、前述のとおり、「IPPを使ってジョブ管理をするアプリケーション」が
IPPなプリンタに印刷するのであればOpenPrintingフレームワークをパスする…
と定義すれば問題にはならないと思うのですが。
| ところで、そもそもPCMはIPPのような高レベルなプロトコルを扱う
| べきでしょうか?(USでも同じような質問をしましたが:スライドの16ページ
| )
| ftp://ftp.pwg.org/pub/pwg/fsg/2004-Nov-SanAntonio%20Slides/FSGOpenPrint_2004-Nov-Plugin_SM.ppt
| 言い換えると、IPPはPCMのスコープ外とすると問題ありますでしょうか?
以下の部分ですよね?
| Provide the API for the common control functions.
| -“Pause”, “Resume” for local port printers as well as IPP ?
| - IPP needs a job identifier to control a job.
この点も整理が必要かもしれません。認識の。
仮にUSBであれ、パラレルであれ、lprであれ、IPPであれ…相手先のプリンタが
どんなプロトコルであれ同一のI/Fによる操作をOpenPrintingフレームワーク内での
上位層へ提供するというのがPCMの役割であると定義するならば、
PCMがwrappingする対象にIPPも含まれると考えるべきでしょうね。
ただ、その場合もPCMが上位層に提供するのは、
IPPに沿った、もしくはIPPに倣ったI/Fとするのではなく、
一般的なファイルオペレーション的な単純なI/Fを提供するのみで、
そのI/Fを通じて上位層から送られた印刷処理をIPPな処理に置き換えて
IPPなプリンタとやり取りをするという仕様ではまずいでしょうか。
その際の要求事項は下記のとおりになると思います。
・Plug-inは、IPPにのっとった形でIPPなプリンタとやり取りを行う
・Plug-inはPCM I/F経由で受け取った印刷データを単一のJob、単一のドキュメントとして印刷処理を行う
・Plug-inはPCM I/F経由で受け取ったStatus取得指示をうけ、
IPP経由で印刷ステータスを取得し、Bi-Di Formatに変換した後単純なストリームデータとして
PCM I/F経由で上位層へ返す
・Status読み取りと印刷データ送出のタイミング調整はPlug-in内部で行われる
つまり、PCMは上位層に対して、IPPライクなI/F、手順は提供しないが
非IPPな手順によるDriverやStatus Monitor等のモジュールからの接続を
変換した上でIPPなプリンタに接続する…という意味では、IPPをスコープに入れるといえますし、
IPPなアプリケーションからのIPP的な接続という意味ではスコープには入れません。
こういうことなら、矛盾は生じないと思いますが、どうでしょうか。
| > > - PrintManagerが生成するJobIDと、IPPから得られるJobIDの対応をPCMが管理
| >
| > これは実際にはPlug-inが管理するということで問題ないでしょうか。
|
| USの議論ではPCMが管理する、ということになっていたと思いますが、
| Plug-inが管理するのでも問題無いと思います。
仮にIPPの処理をPlug-in側に隠蔽化してしまうというのを前提にするならば、
Job IDの変換もPlug-in内部に押し込めてしまうとしたほうがすっきりすると思います。
他のプロトコルをwrappingするplug-inとのplug-in I/Fの統一性も高くなるでしょうし。
他に見落としている事も含めて、どしどし突っ込みいただけると助かります>皆様
_______________________________________________
printing-japan mailing list
printing-japan @ mail.freestandards.org
http://mail.freestandards.org/mailman/listinfo/printing-japan
More information about the Printing-japan
mailing list