[cups.general] An idea how to provide CUPS Browsing for CUPS 1.6
till.kamppeter at gmail.com
Thu Nov 22 05:28:25 PST 2012
On 11/22/2012 12:58 PM, Johannes Meixner wrote:
> this is a request for comments if and how it might be possible
> to provide CUPS Browsing for CUPS 1.6.
> Since CUPS 1.6 the source code that implements CUPS Browsing
> does no longer exist.
> Michael Sweet explained why CUPS Browsing is no longer
> supported by Apple's CUPS.
> As far as I understand from the information that I have
> it seems the background reason why Apple dropped so many
> things in CUPS 1.6 is that Apple does no longer want to
> maintain code in CUPS that is neither used nor tested by Apple.
> If my understanding is right, I would perfectly agree with such
> a decision.
> But I do not agree with the way how this change happened because
> there is no smooth transition possible from CUPS <= 1.5 to CUPS 1.6
> because a CUPS 1.6 server is incompatible for CUPS <= 1.5 clients
> and vice versa.
> But 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.
> For the dropped filters and backends in CUPS 1.6 backward
> compatibility is possible because there is a well known stable
> interface in CUPS how third-party filters and backends can be
> used with CUPS.
> Therefore OpenPrinting.org was able to provide those
> filters and backends that are dropped in CUPS 1.6
> as third-party addon-software for CUPS 1.6.
> All what the Linux distributors have to do is to provide
> the cups-filters software from OpenPrinting.org
> so that for the end-users printing works as before.
> But the dropped support for CUPS Browsing is different
> because there is no well known stable interface in CUPS
> how third-party software could provide CUPS Browsing.
> I do not like to re-introduce CUPS Browsing for CUPS 1.6
> by large patches that each Linux distributor maintains
> on its own, see
> I would prefer if I could provide CUPS Browsing
> functionality via a well separated daemon (cups-browsed)
> as third-party addon-software for CUPS 1.6, see
> This way there would be no change in the behaviour of CUPS 1.6
> and no change in what Apple needs to maintain in CUPS.
> There would be only a separated software that implements
> CUPS Browsing even on a server that runs CUPS 1.6.
> shows a simple proof-of-concept via a Perl script.
> I looked at the CUPS 1.5.4 source code for the cups-polld
> (scheduler/cups-polld.c) and it seems it might be possible
> to enhance it into a generic cups-browsed.
> Currently cups-polld sends a CUPS_GET_PRINTERS request
> for printers and classes to a (remote) CUPS server and then
> it broadcasts the printers and classes to 127.0.0.1 (localhost).
> A generic cups-browsed may request any CUPS server (including localhost)
> for printers and classes and then it broadcasts the printers and classes
> to any set of other hosts.
> To provide CUPS Browsing on a CUPS 1.6 server such a generic cups-browsed
> would request the CUPS 1.6 cupsd on localhost for printers and classes
> and broadcast the printers and classes to CUPS <= 1.5 client hosts.
> I ask for comments if this is possible at all and what you think
> in general about such a generic cups-browsed for CUPS 1.6.
> In particular I would be interested if such a generic cups-browsed
> cannot work on CUPS 1.6 and/or if CUPS <= 1.5 clients that get printers
> and classes this way cannot print "as usual via CUPS Browsing"
> also on a CUPS 1.6 server.
> Kind Regards
> Johannes Meixner
I am also thinking about a cups-browsed, but one which does the client
part: It picks up the Bonjour broadcasts of CUPS servers of version
1.6.x or newer and creates and removes raw print queues in the local
CUPS environment appropriately. So for the end user the whole thing
appears like CUPS in the old CUPS broadcasting/browsing world, both for
CUPS 1.6.x servers which do only Bonjour broadcasting and no CUPS
broadcasting and for CUPS 1.6.x clients which do not do any browsing.
Shortcoming of this is that it does not support legacy CUPS servers
which broadcast only with the old CUPS protocol and not via Bonjour and
it is also not of help for old CUPS clients which expect CUPS
broadcasting from the server to list the server's queues automatically.
Johannes' daemon intends to simply do CUPS broadcasting, making printers
on old clients available when the server is updated to CUPS 1.6. It dos
not support the update of the client to CUPS 1.6.
My suggestion is the universal cups-browsed with three independently
1. Browse Bonjour broadcasts of remote printers and create/remove local
raw queues pointing to these printers appropriately. This recovers the
automatic appearing of remote queues in all-CUPS-1.6.x environments (my
2. Browse CUPS broadcasts of remote printers and create/remove local raw
queues pointing to these printers appropriately. This recovers the
automatic appearing of remote queues for CUPS 1.6.x clients with CUPS
1.5.x (and older) servers.
3. Broadcast local queues in the old CUPS protocol. This recovers the
automatic appearing of remote queues for CUPS 1.5.x (or older) clients
with CUPS 1.6.x servers (Johannes' initial idea).
I would provide upstream hosting for this daemon as part of the
cups-filters package. The build system of cups-filters will make the
daemon optional and packagers should put the filters and the daemon into
separate binary packages so that users/admins can choose whether they
want to have cups-browsed.
Note that this daemon is for backward compatibility with legacy
software. It is not intended to be used eternally.
The new way to do things should follow CUPS upstream and the PWG
standards. This means that printers get broadcasted via Bonjour and
application's print dialogs browse the Bonjour broadcasts to add
available remote printers to their lists. Therefore I have mailed to the
upstream maintainers of the GTK and Qt dialogs requesting the Bonjour
browsing by the print dialog (via cupsEnumDests() of libcups) as an
Johannes, do you (or someone at SUSE) plan to code this daemon?
More information about the cups