[cups.development] [RFE] STR #4085: CUPS filter: only serial, no parallel processing of jobs for one priner

[jsmeix.suse]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR Closed w/o Resolution]

Only FYI an untested proposal:

To decouple filtering from sending the final data
to the printer device, you could set up two queues
for each printer device:

One queue which does the filtering and outputs into a
second queue which is a "raw" queue that only sends
the final data to the printer device.

Applications must submit their print jobs only
into the queue which does the filtering.

Because the backend of the filtering queue which
outputs into the "raw" queue is usually run as user "lp"
it might work to allow only the user "lp" to submit
print jobs into the "raw" queue ("lpadmin -u allow:lp ...")
so that usual user applications cannot submit print jobs
into the "raw" queue.

This way filtering for a subsequent job can run
while the final data of a previous job is still
sent to the printer device.

To even run filtering for several jobs simultaneously
you might set up several such filtering queues and
have them all in a class and all those filtering queues
output into a single "raw" queue that sends the final
data to the printer device.

In this case applications should submit their print jobs
into the class.

A drawback when filtering for several jobs run simultaneously
is that the ordering how jobs come out of the printer device
can be different compared to the ordering how jobs have been
submitted into the class by applications because a small/fast
filtering job can get ahead of a big/slow filtering job.

A general drawback of several queues for one printer device
is that it is no longer possible to get the state regarding
one printer device via a single "lpstat -p queue ..." call.

Link: http://www.cups.org/str.php?L4085
Version:  -feature
Fix Version: Will Not Fix