IPP Mail Archive: RE: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]

RE: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]

kugler@us.ibm.com
Wed, 5 May 1999 14:51:37 -0600

Couldn't you use the same approach for "number-of-intervening-jobs"?

In reality, I suspect that most Printers will simply return the jobs in order of
submission, except that "job-hold-until" and "job-priority" should be taken into
account (along with any policy like "shortest job first"). Trying to predict
the order of completion is just too complex where a single Printer fans out to
multiple output devices. Consider an IPP gateway to a DPA (ISO 10175) printing
system. A typical DPA architecture would include a Print Operation Manager, a
Spooler, and a Supervisor. The IPP Printer could be mapped to a DPA Logical
Printer. In some configurations, a single logical printer might represent
multiple physical printers, and a single physical printer might be represented
by multiple logical printers. Jobs submitted to the Printer go to the spooler,
which might contain multiple queues. The supervisor(s) assign(s) jobs from the
queues to physical printers according to the capabilities and availabilities of
the physical printers. In this scenario, it will be hard enough to predict the
order in which the jobs will start processing, let alone complete. The IPP
logical printer will need intimate knowledge of what's going on in both the
Spooler and the Supervisor. Of course, there may be intervening jobs that were
submitted to a different IPP logical printer, or foreign jobs submitted by other
means.

-Carl

"Anthony Porter" <anthony.porter@computer.org> on 05/05/99 01:28:18 AM

Please respond to anthony.porter@computer.org

To: "'Paul Moore'" <paulmo@microsoft.com>, Carl Kugler/Boulder/IBM@IBMUS,
ipp@pwg.org
cc:
Subject: RE: RE: IPP> MOD - Use of time [and Bake Off 2 Issue 17]

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@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Paul
Moore
Sent: 04 May 1999 17:57
To: 'kugler@us.ibm.com'; ipp@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@us.ibm.com [mailto:kugler@us.ibm.com]
Sent: Tuesday, May 04, 1999 8:47 AM
To: ipp@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