[cups] Is client.conf really deprecated on all platforms?

[Michael Sweet]

Johannes,

> On Oct 30, 2015, at 12:45 PM, Johannes Meixner <jsmeix at suse.de> wrote:
> 
> 
> Hello Michael,
> 
> On Oct 30 11:49 Michael Sweet wrote (excerpt):
>> You'll always be able to use the CUPS_SERVER environment variable
>> to specify an alternate "default" server, however the CUPS design
>> has always been to have a local cupsd that handles communications
>> with the remote server or printer, doing filtering as needed.
>> Direct submission to remote servers is problematic.
> 
> Could you provide some reasons why direct submission
> to remote CUPS servers is problematic.

Network is down.

VPN is down.

User closes lid on laptop before application is finished submitting.

Application hangs due to networking issue.

Application (or toolkit) doesn't know enough to retry network errors, preventing printing because the server was not accessible at startup.

> Currently I do not understand why having a local cupsd
> in between is an advantage.

The local cupsd can coordinate with the OS to keep the system (and network stack) up long enough to send the job remotely.  The local cupsd can also handle conversions of application supplied print data into a printable form.  And the application won't block for as long - local domain sockets are several orders of magnitude faster than network sockets.

Mobile devices (including laptops) are not tied to a single infrastructure, and such devices outnumber desktops by at least 10:1, so pointing at a single server and treating it as a common configuration doesn't match with reality.

> I would even expect the opposite that direct communication
> with the final CUPS server (e.g. a company print server)
> where I want my document to be processed and printed
> is better than having "another level of indirection"
> in between (cf. RFC 1925 item 6a ;-)

If the server is down, the network is down, the VPN is down, etc. then the application/user will be unable to print.  With the local cupsd you can queue up a job and recover from temporary issues much more easily, and your client software can adapt to the network/location more easily (e.g., home printing vs. work printing).

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair