On Fri, 2013 Jun 21 9:29-0400, Michael Sweet wrote: > > Well, before we go off and spend extra engineering time on this, how > widespread is the use of client.conf in the Linux world? On OS X it > was pretty-much non-existent (less than 1% of users, based on bug > reports) and since 10.8 *is* non-existent since we had to drop support > for it entirely there (not all applications ask for networking access, > and without network access you can't talk to a remote cupsd...)
client.conf is applicable to large-site/institutional/enterprise deployments of CUPS. How important is this use case to you? Beyond that, it almost sounds likes CUPS as a whole is scaling down into a local-only print infrastructure, that networked printing support is no longer a goal. Is that really where things are going? > Would simply adding some additional text to the client.conf man page > be just as helpful, e.g.: > > ServerName hostname-or-ip-address[:port]/version=1.1 > Specifies the address and optionally the port to use when > connecting to a server running CUPS 1.3.12 or earlier. > Note: Not supported on OS X 10.7 or later. > > ServerName hostname-or-ip-address[:port] > > ServerName /domain/socket > Specifies the address and optionally the port to use when > connecting to a server running CUPS 1.4 or later. Note: > Not supported on OS X 10.7 or later. Documenting these directives is helpful, but how are users going to recognize that an IPP version incompatibility is the problem in the first place? How would they know that they should care what version of CUPS is running on the server, when it's working perfectly well with older clients? Right now, all they get is a generic and/or spurious error message that isn't even good for a Web search. -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371838822.32740.140661246926253.3585c...@webmail.messagingengine.com