[cups.development] cupsd to backend interface

[Jim Fehlig]

While developing a backend I have encountered some issues that have 
proved difficult to solve.  They all appear to be a consequence of a 
backend's exit options - zero for success or non-zero in the event of an 
error.  Consider the following scenarios.

cupsd invokes the backend to submit a job.  The backend contacts the 
recipient but it does not accept the job due to

- authentication credentials missing or wrong
- job size too big
- user not permitted to access the queue
- job data format not supported by the server
- ...

So for this job, parameters are missing that prevent successful delivery 
to the recipient.  What should a backend do in this case?  If it 
finishes with a zero exit code the job is lost.  If it finishes with a 
non-zero exit code the whole queue is disabled, preventing other jobs 
from being delivered to the recipient even though they may be accepted.

For the case of authentication credentials missing, I have considered 
using IPC to communicate with a process started when the user logs in.  
This "user process" could then prompt the user for credentials and pass 
them to the backend, which would in turn forwards the credentials to the 
recipient.  But what if the user logged in remotely via ssh or job was 
submitted via cron, in which case the "user process" would not be running?

For the job size too big case, consider print jobs > MAX can only be 
submitted between 6pm and 8am.  What should a backend do?  It could 
block until the window opened but in the meantime no valid jobs could be 
submitted to the recipient and are instead queued locally.

All of the cases described above are specific to a job only and a 
backend has no way to communicate to cupsd that "something is wrong with 
this job and I cannot process it but I am ready for other jobs".  I know 
that backends can write status information to stderr that subsequently 
can be consumed by the cups web interface, lpstat, etc., but what if the 
backend needs additional information (e.g. credentials) before proceeding?

I considered submitting an enhancement STR to define semantics 
associated with backend exit codes but wanted to see if there are 
options I have not considered.  An example of semantics associated with 
backend exit codes:

- Exit code 1 indicates a fatal error regarding the remote queue.  
Further job submission attempts would be futile, so cupsd disables the 
queue.
- Exit code 2 indicates a fatal error regarding the job.  The job is 
held until the owner takes action to correct the condition, e.g. 
supplies credentials, deletes the job, etc.  The queue is not disabled 
in this case thus jobs can continue to be submitted.
- Exit code 3 indicates a temporary error occurred while submitting the 
job.  The nature of the error is such that the job should be retried,  
e.g. a network error occurred while transmitting job data.  cupsd would 
retry the job immediately.  One could argue that the backend should 
handle this case but has been included since we are discussing exit code 
semantics.
- Exit code 4 indicates a temporary error occurred while submitting the 
job.  The nature of the error is such that the job should be requeued, 
e.g. user only allowed to print jobs > 5Mb between 6pm and 8am.  cupsd 
would requeue the job and attempt submission at a later time.
- Any other exit codes that might be useful??

I realize that many details have been ignored in this discussion but 
just wanted to see how other backend writers are handling issues related 
to job-specific failures when communicating with their targets.

Best regards,
Jim