That's right, we haven't the faintest idea when a job will be printed, but
'expected' lets us off the hook. In fact we just return the jobs in order
of submission, so if someone holds a job, it doesn't jump to the bottom of
the list, because we 'expect' it to be released again.
-----Original Message-----
From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Paul
Moore
Sent: 04 May 1999 17:57
To: 'kugler at us.ibm.com'; ipp at pwg.org
Subject: RE: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]
the word 'expected' is included in the requirement - I think this means best
guess.
This is , after all, only a printing system (as opposed to NORAD or the
flight control system of a B1 bomber).
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Tuesday, May 04, 1999 8:47 AM
To: ipp at pwg.org
Subject: Re: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]
>> number-of-intervening-jobs is much harder to implement because you have
to
> 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
but
> 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.
-Carl