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

[Johannes Meixner]

Hello,

On Nov 22 14:00 Michael Sweet wrote (excerpt):

> ... technical issues ...

I do not talk about technical reasons because technical reasons
why CUPS Browsing is dropped are actually meaningless for users
where CUPS Browsing "just works" for them.


> 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)?


Requiring a different protocol how the queues on the CUPS server
are made available on the clients (i.e. replacing BrowseProtocol
CUPS by BrowseProtocol DNSSD) is not what I mean with backward
compatibility, see what I wrote:

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.

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

I am afraid but from my current point of view it looks as if
you and/or Apple do not understand what "reasonable period of time"
and "older versions" means in our (i.e. SUSE) customer's
business environments.

Our current SUSE Linux Enterprise 11 products have CUPS 1.3.9
and we support many customers that run SUSE Linux Enterprise 10
which has CUPS 1.1.23.

My concern is how to provide backward compatibility for business
environments where servers and clients run various CUPS versions
down to CUPS 1.1.23.

Enforcing our business customers to upgrade CUPS everywhere on
their stable running production systems (servers and clients)
is not at all an option.


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.

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.

One kind of such optional printing-related services are whatever methods
and protocols how queues on a server can be made available on whatever
kind of clients (form smartphones up to big business database systems).

Another kind of such optional printing-related services are the
various ways to convert the print job data that is provided by
the client (e.g. PDF) into printer-specific data (e.g. JCL+PCL).
This services are optional because for the core plain printing
service "raw" queues are sufficient.
This optional services are already separated from what the cupsd does
but the cupsd provides a well known stable interface how this optional
service can be added to the core plain printing service.

Perhaps it makes sense to have a stable interface how optional services
that make queues on the server available on clients can be added
to the core plain printing service.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer