Good point. Lets call the values of the job-scheduling-policy printer
attribute: first-come-first-served, and smallest-job-first.
The smallest job first can be as simple as smallest number of octets.
A smarter system might use the number of pages.
A printer that rips first and then marks, will know after ripping what
is really the number of pages and might delay the big ripped job in favor
of short jobs. Sort of an "express printer".
Remember that a Printer object can be implemented in a big fancy spooliing
systems that supports one or many output devices. And a Printer object
can be implemented in a simple output device that only takes one job
at a time. Such a printer would only support the value:
first-come-first-served (as I expect most implementations will).
At 11:20 11/22/96 PST, JK Martin wrote:
>Angelo wrote (in response to Tom Hasting's comments):
>>> Under 10. b) you list shortest-job-first as a scheduling algorithm. How
>> does a printer determine the shortest job? A small file size does not
>> neccessarily imply a short RIP time.
>>A very good point. Perhaps this attribute should be "smallest-job-first"?