Comment 5 for bug 187049

Wouldn't it be the best possible solution when the backend
and only the backend cares about the firmware stuff?

I mean to have no udev magic at all.

Just let the backend do a firmware upload whenever there are
device communication problems with those low-level devices
at tha beginning of a print job.
Of course preferably if the backend could detect if the device
has already firmware or not.
The backend could re-try to do a firmware upload in an infinite
loop until it is successful.
Only when there are device communication problems after
a successful firmware upload, the backend should abort with
CUPS_BACKEND_FAILED or CUPS_BACKEND_STOP.

This should also avoid the mess when there are pending print jobs
while the device is powered-up because the backend would notice
when it fails to send the first piece of print job data to the device
and then it could do a firmware upload and re-send the print job data.

Furthermore (in contrast to udev) the backend can show
matching INFO:/WARNING:/ERROR: messages to keep
the user informed what is actually going on.

For background information what I have in mind
regarding "infinite retries for a CUPS backend", see
https://bugzilla.novell.com/show_bug.cgi?id=337794#c16
----------------------------------------------------------------------
As long as the backend cannot establish a communication with its
recipient, it cannot cause damage when it loops infinitely and
retries again and again (with a reasonable sleep time between
each retry).

In contrast if a working communication with its recipient crashes,
it should not re-try the same job (which means print it again from
the beginning).
----------------------------------------------------------------------

What do you think?