[cups.development] cupsd to backend interface
Jim Fehlig
jfehlig at novell.com
Tue Feb 8 07:51:55 PST 2005
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
More information about the cups
mailing list