Comment 6 for bug 458999

Ok let me try to explain how the next version of the "hp" backend handles errors. There are two error conditions I will expand on.

1. Device connect errors.
      a. Device communicates, but is busy.
      b. Device fails to communicate.

2. Device write errors.
      a. User recoverable error, out-of-paper, lid-open, paper-jam, etc...
      b. Non recoverable hardware error.

Some errors will exit and some will loop forever until cleared.

Exit codes used:
      0 = ok
      1 = job failed, use error-policy
      4 = job failed, stop queue

Device connect error definitions:

exit code | condition a. | condition b. | CLASS env.
          | (busy) | (fails) | set
----------+---------------+--------------+-----------
    1 | x | | x
  loop | x | |
    1 | | x | x
    1 | | x |

Device write error definitions:

exit code | condition a. | condition b.
          | (recoverable) | (non-recoverable)
----------+---------------+------------------
  loop | x |
    4 | | x

As you can see only device connect errors will have the option to retry the job. Non recoverable write errors will stop the queue. Recoverable errors will loop forever with 30-70s delays.