[printing-japan] Question about requirements for PCM

Ide Kentaro Ide.Kentaro @ exc.epson.co.jp
2005年 1月 20日 (木) 10:01:50 PST


井手です

とりあえずPCMが上位に対してはIPP I/Fを提供しないという前提で
整理を進めさせてください。
#ほとんど独り言と化してますが今しばらくご容赦を

私が書いた
| 仮にUSBであれ、パラレルであれ、lprであれ、IPPであれ…相手先のプリン
| タが
| どんなプロトコルであれ同一のI/Fによる操作をOpenPrintingフレームワーク内
| での
| 上位層へ提供するというのがPCMの役割であると定義するならば、
| PCMがwrappingする対象にIPPも含まれると考えるべきでしょうね。
| 
| ただ、その場合もPCMが上位層に提供するのは、
| IPPに沿った、もしくはIPPに倣ったI/Fとするのではなく、
| 一般的なファイルオペレーション的な単純なI/Fを提供するのみで、
| そのI/Fを通じて上位層から送られた印刷処理をIPPな処理に置き換えて
| IPPなプリンタとやり取りをするという仕様ではまずいでしょうか。

この点について、IPPと特定しているわけではないのですが、
過去の議論で指摘された課題点で関係するものを書き出します。
11月のUS行き直前の議論を基に虎谷さんがまとめられたものから抜き出して
その後の議論の内容を踏まえて修正している部分もあります。
==================ここから
[印刷データ出力]
 1)Plug-in側でプロトコル変換を行う場合、プロトコルによって、
  書き込み準備と一定バイトで区切られた連続データの組み合わせが
  1:nな場合と1:1の場合が存在する。

	> StartDoc、EndDocの必要性

 2)印刷の中断処理はデバイスや通信プロトコル毎に異なるため、
  印刷中断処理を隠蔽する仕組みが必要

	> StartJob、EndJob、CancelJobの必要性
	  Job ID管理の必要性


[ステータス取得]
 3)(ステータスのデータ長)<(呼び元のバッファ長)とは限らない。
  よって、呼び元が呼び元のバッファ長に合わせて、複数回に分けて
  ステータスを取得しつつ、ある時点で全てのステータスデータの取得が完了
  したことを知るための仕組みが必要。


 4)呼び元が複数回に分けてプリンタステータスを取得している間は、
  プラグイン側でステータスの内容を更新してはいけない。よって、呼び元が
  ステータスを読み込んでいる間はプラグイン側でステータスの更新を休止し、
  ステータスの読み込みが完了したら、次に呼び元に読み込まれるべき
  ステータスを更新可能とする仕組みが必要。

 5)ステータスデータが準備できていない間は、可能な限り印刷データを
  出力するために、ステータスデータが準備できているか否かを呼び元が
  知る仕組みが必要。かつ、呼び元のポーリング間隔に達していない場合は、
  ステータスデータが準備できていても、呼び元が印刷データを出力し続ける
  ことを可能とする仕組みが必要

[コントロール系]

 6)印刷の一時停止、再開など、共通的な操作に類するものについても
  デバイスやプロトコルの違いを隠蔽する仕組みが必要

	> 未定義

 7)複数回に分けたステータスの取得の途中で、印刷データの書き込みを
  受け付けるか否かは、プリンタに依存。よって、印刷データの書き込みと
  ステータスデータの読み込みの排他を可能とする仕組みが必要

==================ここまで

ここまでの要件事項の前提は、PCMの下位=Plug-inでwrappingする対象として
下記の部分を包含していることである
これは、Job系、Doc系のキックをOpen/Close系で行うとする場合でも原則同じ
仮に、Hi-end PCMとする

	・高位の通信プロトコル
		・IPP、USB経由でのプリンタ制御プロトコル等
	・ステータスデータ
		・機種依存コードからfsg formatへの変換など

一方で、PCMでwrappingする対象を下記の範囲とした場合のPCMを
仮にLow-end PCMとする

	・デバイスファイルのI/O
	・Networkの低位層(socket程度?)
	・I/Oコントロール
		・出力時のプリンタ側でのエラー発生に対するunti-deadlock機能も含む
		・Read/Writeの排他機構(ポートロックの実装)


Hi-end PCMのメリットデメリット
 [メリット]
	・フィルタやSMアプリの仮想化レベルが上がる
	・仕様と実装の対比が容易である>仕様のモジュール≒実装時のモジュール
 [デメリット]
	・PCM I/Fでの入出力とデバイスに対する入出力の間の非同期化
		>リソースの増大傾向
		>パフォーマンスの低下???

Low-end PCMのメリットデメリット
 [メリット]
	・PCM I/Fの単純化
	・PCM(I/F)で多種のプロトコルを考慮する必要は無し
	・リソース多重化の低減
		>出力するべきプリンタの特性に合わせ出力データに上位層で変換し、
		 スプールしたものをシーケンシャルに出力していくだけ。
		 出力終了したらClose
		>PCM I/Fとデバイスに対する入出力の間はほぼ同期
 [デメリット]
	・仕様と実装の対比は1:1にしにくくなる
		>SM(Bi-Di Plug-in)とドライバの連結度は高くなる
		 場合によっては一つのモジュールとして実装される?
	・ポートの仮想化程度は低くなる


議論のすれ違いは、Hi-endとLow-endのどちらを念頭において論じているか
ということなんでしょうか?




More information about the Printing-japan mailing list