Bug#704238: Need to document the CUPS client's new server-version option
Daniel,
On 2013-06-21, at 2:20 PM, "Daniel Richard G." <skunk@iSKUNK.ORG> wrote:
> 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?
My experience with large sites has been the opposite - most places I've worked with have departmental print servers with manually-added queues (either raw queues or the OS X-style local queue/PPD forwarding to the server). They typically do not run all of the clients through a single print server because of performance issues, and use local PPDs to avoid hitting the print server every time someone opens the print dialog...
> 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?
Not at all.
cupsd itself hasn't changed all that much. We dropped support for CUPS browsing (serious performance and scaling problems for large networks, and a huge power drain in mobile devices) and our ad-hoc SLP/LDAP schema (serious deployment issues) in CUPS 1.6 in order to re-wire things to better support large and mobile networking.
At the client level, we changed the focus from a static list of printers provided by a single server to a dynamic list of printers provided by multiple servers - definitely large network stuff. Right now the dynamic lookup happens only with DNS-SD, but future versions of CUPS will also look things up via SLP and LDAP using the standard schema (again, large network stuff).
Other future work: check out the IPP Shared Infrastructure Extensions on pwg.org; this will likely be supported by cupsd and solves many of the network/security barrier issues common in large networks.
So no, we aren't focused on local-only print - that's all we had previously. We are now tackling large network/Internet printing and network mobility, something CUPS has traditionally been very bad at (thus hacks like client.conf and CUPS browsing).
>> 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?
Presumably the admins telling them (or configuring their system) to use the server will instruct them accordingly. Or perhaps run server software newer than 4 years old?
> 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?
Presumably the users will know what the admins are telling them, and the admins will read the documentation?
> Right now, all they get is a generic and/or spurious
> error message that isn't even good for a Web search.
We tried doing auto-version-detection and that didn't work.
Getting a Bad Request in lpstat/lpq and retrying with a 1.1 request to display an error telling the user to fix their configuration (!?!?) isn't particularly useful IMHO, and is more likely going to have users asking why the f**k we don't just do a 1.1 request in the first place.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Reply to: