[cups.development] Re: [RFE] STR #1382: Please pre-process next document while printing current document

[Johannes Meixner]

Hello,

On Jan 20 05:06 Till Kamppeter wrote (shortened):
> Define 2 queues:
> 1. A first queue with the driver/PPD for your printer selected ...
> 2. A second queue which is a raw queue with a backend ...
.... 
> It would be nice if this could be a standard feature of CUPS or if at
> least such a configuration could be done automatically (option in web
> interface or so).

Ahh - we are back to the old LPD-style seperated filtering
and forwarding queues ;-)

In general I don't like several queues for one printer because
this is difficult to set up, to maintain and to understand by
the users (local users may still "see" both queues).


I was thinking about a different solution:

Use a "buffering backend wrapper".
I mean something like the "beh" backend wrapper but with the
functionality to create a buffer-file in /var/spool/cups/
and then run the actual backend with this buffer-file as argv[6]
as seperated independent process.
As soon as the actual backend has opened the buffer-file, it should
be possible to run a remove command by the "buffering backend wrapper"
and let the "buffering backend wrapper" finish successfully.

But this seems not to work as easy as I expected on the
first glance because:

a)
The "buffering backend wrapper" could cause that several processes
with the actual backend run at the same times so that mutual 
exclusion is necessary, i.e. the actual backend may require
another "mutual exclusion wrapper" - on the other hand any
normal backend must retry connections to the device so that
mutual exclusion may work out-of-the-box.

b)
The user cannot stop printing the current job by removing it
from the queue because when printing starts it is actually
removed from the queue and only the independent actual backend
process prints the buffer-file (which is the known problem
that may users reported that they cannot stop a printing job).
The same is true to a certain extent for Till's proposal:
The user may not understand from which of the both queues
a job must be removed to stop printing.

c)
The "buffering backend wrapper" would always finish successfully
(except something like "out of disk space") so that no error
of the actual backend could disable the queue.
I.e. the new CUPS error policy would be useless in this case.


Furthermore:
I do not understand why there is such a long delay before
the Xerox Phaser 6100 starts to print.
As far as I know the filters and the backend run simultaneously
so that the backend sends the first data blocks to the printer
as soon as they are spit out from the last filter.
The printer should start to print as soon as the first page
was processed by the filters.


Therefore my current summary is:
For special cases I like Till's proposal very much.
In general I prefer the usual one by one job processing.
I think there is no need for such a feature in CUPS.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/