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

Till Kamppeter till.kamppeter at gmail.com
Thu Nov 22 05:28:25 PST 2012


On 11/22/2012 12:58 PM, Johannes Meixner wrote:
>
> Hello,
>
> 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
> http://www.cups.org/newsgroups.php?s1+gcups.general+v9+T0+Q%22how+to+get+printers+on+mac+os+10.8+from%22
>
> 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
> https://bugzilla.novell.com/show_bug.cgi?id=735404#c7
>
> 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.
>
> https://bugzilla.novell.com/show_bug.cgi?id=735404#c10
> 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 
switchable functions:

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 
initial idea).

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 
urgent feature.

Johannes, do you (or someone at SUSE) plan to code this daemon?

    Till







More information about the cups mailing list