[cups.general] When should a network backend retry?

[Johannes Meixner]

Hello,

FYI where to find the initial bug report and discussion:
https://bugs.launchpad.net/hplip/+bug/458999

On Oct 29 14:09 Michael R Sweet wrote:
>
> Ok, so the general rule is that a backend should retry all non-fatal
> errors. In the case of the standard CUPS network backends, we don't
> retry failed lookups or routing errors, but we *do* retry connection
> failures and other "busy" indicators. Thus, the error policy
> determines what happens for uncommon/unexpected problems that may
> require admin attention.

Are failed lookups or routing errors really fatal errors
in any case nowadays?

I understand that in a traditional "static" network environment
those errors are "fatal" with the menaing "admin required".

But what about nowadays kind of "dynamic" network environments
like a user who moves around with his laptop in a wireless
networking environment (e.g. in a big company where this
or that network printer may become available or not)?

I don't have good knowledge about such network environments.
Therefore I like to ask whether or not failed lookups or
routing errors are still fatal even in this case.


> On Oct 29, 2009, at 10:48 AM, Tim Waugh <twaugh at redhat.com> wrote:
>
>> If a network backend fails to connect to its network device because
>> the
>> device is not currently present on the network, should it retry or
>> exit?
>>
>> The current CUPS backends retry in this situation.  However, the HPLIP
>> 'hp' backend exits -- this is apparently in order to allow the printer
>> error-policy to determine the behaviour.
>>
>> So is error-policy meant to cover connection failures where the device
>> is not present on the network?  I haven't managed to find any
>> definitive
>> documentation about this.
>>
>> Thanks,
>> Tim.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex