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

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

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

kugler at us.ibm.com kugler at us.ibm.com
Wed May 5 16:51:37 EDT 1999

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


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

Please respond to anthony.porter at computer.org

To:   "'Paul Moore'" <paulmo at microsoft.com>, Carl Kugler/Boulder/IBM at IBMUS,
      ipp at pwg.org
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 at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Paul
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

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
> 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.


More information about the Ipp mailing list