[cups.development] Define the printer list

[Michael R Sweet]

Francis Giraldeau wrote:
> Hi,
> 
> We face an issue with the printer list displayed to the user in large
> environment. We need the ability to display only some of the printers,
> since other printers are not relevant.
> 
> We did that by changing libcups cupsGetDests to make it return only
> selected printers, based on a configuration parameter. That way, all
> cups aware applications are getting the same printer list, and no
> changes on server side are necessary.
> 
> The patch is based on glib, so I guess it has to be reimplemented to
> avoid adding a new dependency to libcups, and probably needs major
> rework, but the idea is there.
> 
> https://svn.revolutionlinux.com/MILLE/XTERM/branches/ltsp-cluster/cups-client-filter/libhideprinters/libhideprinters.c
> 
> We are looking for a permanent solution for this problem. Comments welcome.

OK, don't expect to see a solution like this in CUPS.  What you might
see is the ability to make use of the location and type filters, and
possibly some host/printer filtering in the client.conf file.

The way this issue has been "solved" on Mac OS X is to use a per-user
plist (XML) file to track "favorite" remote printers, such that users
can choose one or more remote printers to show in the print dialog in
addition to the local queues.  In 10.4, a "Shared Printers" submenu was
used to pick remote printers, which then were promoted to the top-level
printer chooser menu.  In 10.5, the user picks the printers from the
Add Printer window instead.

.....

Some specific feedback on your patch:

1. Using a library to override functions from libcups is extremely
    fragile for day-to-day use.  It also makes it hard for developers
    to track down problems introduced outside of the CUPS sources.
2. Redefining CUPS_GET_PRINTERS is not a good idea.
3. Using strcpy + strcat leaves you open to many possible buffer
    overflow attacks; a single snprintf fixes that issue.
4. For a patch that is supposed to help for large numbers of printers,
    you do a lot of logging which will slow things down.
5. The whitelist approach will cause a lot of usability problems; we
    have the same problems on Mac OS X to a lesser extent since the
    whitelist only applies to remote printers.
6. When you adjust the attribute pointers you aren't freeing the
    attributes themselves, leading to a large memory leak.
7. You never free the GList's you create - more memory leakage.
8. Fix the "no default printer" bug in Mozilla, not CUPS.  There is
    a reason why we return NULL when the user's default printer is
    not available, and your patch will cause confusing and inconsistent
    behavior!

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer