>> number-of-intervening-jobs is much harder to implement because you have
> take account of priorities, paper required and so on. I wasn't able to
> implement this attribute at all because the printer does not queue jobs
> takes the most suitable when it needs work.
>I'll bet you also have difficulty meeting this requirement on the
(REQUIRED) Get-Jobs operation:
Jobs are returned in the following order:
- If the client requests all 'not-completed' Jobs (Jobs in the
'pending', 'processing', 'pending-held', and 'processing-stopped'
states), then Jobs are returned in relative chronological order
of expected time to complete (based on whatever scheduling
algorithm is configured for the Printer object).
For a Printer with two Postscript output devices capable of running in
parallel, for example, it can be proven mathematically that it's impossible
to predict the order of completion in less time than it would take to
interpret all the Jobs (due to the Halting Theorem). Then there are all
the other factors you mentioned, like priorities and paper required, not to
mention "job-hold-until", etc.