Comment 11 for bug 458999

Caution: Long answer!
;-)

I like to explain some more background why I think that
a backend should retry in any possible case
when it is about to establish the communication.

From my pint of view the crucial idea behind is to
keep the control at the user as long as possible.

Initially the "hp" backend has the control which means
that you (both "you" as the author of the "hp" backend and
"you" as the HP company which makes the printer device
and its driver software) has the control what happens
with your customer's (the one who bought your printer)
print job in case of a problem.

As long as you let your backend run, you can communicate
with your customer via stderr messages in case of a problem.

As long as you let your backend run, your customer
has the control what should happen with his print job
in case of a problem because he can decide for each
individual print job to keep the backend retrying or to
cancel the whole job.

In contrast when you give up (i.e. exit the backend)
you withdraw the individual job control from the user
and plunk down the whole stuff and let the cupsd
do whatever it will do with your user's job.

But the cupsd is generic software which can only
act based on generic general rules (e.g. error policy)
which are set up by an admin but out of the control
of the individual user who had submitted the print job
and in the end the result is likely an annoyed HP customer.

For example think about a travelling user with a laptop
who submits a job to a print queue for a network printer
(which is of course not accessible at all while travelling).

Here "travelling" also means when the user walks with his laptop
through a bigger company building using wireless networking
where this or that network printer may become available or not.

When your backend just keeps retrying everything is
perfectly o.k. because:

If the user submitted the job by mistake to this queue
he can easily cancel it.

When the user submitted the job intentionally
to this queue to get it printed whenever the connection
to the printer can be established, your backend must
keep retrying for a long time (e.g. for one week).

In contrast the company admin who may have set up
the laptop cannot decide in advance via whatever
setting for the cupsd what should happen with each
individual print job.

By the way regarding "If retry-job is prefered, then the
default error-policy should be changed":

Usually no.

A default error-policy "retry" is usually not possible
because it results endless printing of the same job
again and again for certain issues with network printers
which fail to communicate correctly a "success" at the
end of a job.

Only a queue specific error policy "retry" may help here
but why should the cupsd retry the whole job
(i.e. also re-run all the filters and so on) only because
the backend cannot establish the communication?

If the error during communication startup is really fatal
(ony the backend can decide this), the bakend must
stop the queue (because job retry does not make sense)
and in any other case the backend must retry.