[cups.general] Best practice for setting "ErrorPolicyretry-job"on all defined print queues?

[Johannes Meixner]

Hello,

On Aug 2 12:55 Michael Sweet wrote (shortened):

> J.B. Nicholson-Owens wrote:
>> Michael Sweet wrote:
>>> There is no "all" class - you'd had to add every printer to a class,
>>> assuming that you wanted to randomly print to one of those printers.
>>
>> Bummer.  I was tempted to use the class approach because of my
>> understanding that classes also let you set a policy (such as retry-job)
>> once and the class will propagate that policy to all printers in the class.
>
> Nope.  In fact, classes only support the "retry-job" policy...

I didn't find a descripion of the ErrorPolicy behaviour for classes at
http://www.cups.org/documentation.php?VERSION=1.4
(but I may have missed it somewhere).

Could the ErrorPolicy behaviour for classes be described in
http://www.cups.org/documentation.php/doc-1.4/ref-classes-conf.html

Even if there is only one (hardcoded) ErrorPolicy behaviour for classes,
it would help to have it described.

If a class does always "retry-job" in case of an error
what exactly does this mean?

I assume "retry-job for a class" means that when the job fails on
a particular queue "this" then it retries the job on another queue
in this class e.g. "that".

But what would happen if job fails also on the queue "that"?
Would the "retry-job for a class" with two queues then toggle
infinitely between "this" and "that"?
Or would it do an infinite "round robin" if there is a class
with several queues but all queues fail continuously?

And what would happen if the class contains only one queue?

Or if the class contains several queues but only one queue
accepts jobs (e.g. because the other queues exists only
to have readymade fallbacks available which could be
easily activated by the admin if needed)?


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex