[cups.general] An idea how to provide CUPS Browsing for CUPS 1.6

[Michael Sweet]

Johannes,

Comments below...


Sent from my iPad

On 2012-11-23, at 4:44 AM, Johannes Meixner <jsmeix at suse.de> wrote:

> ...
>> As for the transition, there have been Avahi patches for CUPS since 1.4
> 
> You are no longer against when Linux distributors change how
> CUPS works (usually via patches that each Linux distributor
> maintains on its own)?

In general we aren't crazy about arbitrary patches, but in this case the Avahi patch was something we had wanted to implement already but needed cooperation with the Linux distros to work out the issues like having Bonjour enabled by default, .local lookups wired up properly, etc. Similarly we added GNU TLS support in addition to CDSA, OpenSSL and SSPI.

> ...
> For a Common Unix Printing System there must be backward
> compatibility for a reasonable period of time which means
> that newer versions still work together with older versions
> both on servers and clients in a mixed network environment.

Indeed, and with the exception of browsing and some charset issues I think our history of backwards compatibility has been great. But each of these things has known workarounds...

> The interesting part is what "reasonable period of time"
> and "older versions" means from my point of view.

Three years between CUPS 1.4.0 and 1.6.0. Five years between 1.3.0 and 1.6.0. Oh, and you can still (with some minor config file tweaks) print from a 1.0.0 client (13 years old) to a 1.6.x server, and use a pre-1.6.0 client to BrowsePoll a 1.6.x server and relay the results to the appropriate subnets.

> ...
> Something for the future:
> 
> I know about at least one big business customer who does not want
> to have CUPS linked with "optional" libraries (i.e. libraries
> that are not strictly required for a plain printing service).
> 
> In particular this business user does not want CUPS to be linked
> with Avahi because he does not want to care about whatever
> possible issues with such "optional" libraries (like the
> cupsd crashes in the past and recently because of Avahi).
> 
> This business user wants to have a rock solid plain printing
> service in his particular environment (I assume he even does
> not use CUPS Browsing).
> 
> Regardless that the use case of this business user is not a
> standard end-user/home-user use case, it is a reasonable use case
> and a Common Unix Printing System should also support such users.

That's one of the reasons why we make pretty much everything optional, with reasonable defaults for an out of the box experience.

> ...
> This leads to the question for future CUPS versions whether or not
> it could be a reasonable approach to get the core plain printing service
> (i.e. cupsd) separated from optional printing-related services.

There are some serious performance, stability, and management issues with this approach. Both the client and server side require some form of trusted IPC or dynamic run time loading, both of which pose portability and stability issues (just look at the nightmare that is Firefox for printing...)