autoadd only works with hard-coded driver list

[tillkamppeter]

Describe the bug
My PostScript Printer Application generates the list of available drivers based on the PPD files available in the Snap (or generally in pre-defined directories) instead of hard-coding them in the code of the Printer Application itself (as hp-printer-app does).
With the fix of issue #42 I am now able to build the driver list out of the system_cb() callback, by calling ps_setup() after creating the system. This way I can create the driver list when the system is already there, to be able to log the driver list creation process.
Now I have a server running (which has its driver list built, as a server requires to create a system) and want to auto-add the available printers.
So I run ps-printer-app autoadd, the available printers get auto-added, but all with the "generic" driver using a "Generic PostScript Printer" PPD and not the PPD for the detected printer. This happens because the autoadd callback (ps_autoadd() in ps-printer-app.c) is run without having a driver list, as ps-printer-app autoadd does not create a system (as ps-printer-app drivers does) nor does it somehow load the driver list from the server process (is this possible?), nor does it simply send the "autoadd" command to the server process and the server process does everything then.
The ps-printer-app autoadd does nothing more than only asking the server to auto-discover the printers, not to assign drivers to them. The drivers it tries to assign the drivers by itself, which fails (fallback to "generic") as it did not obtain the driver list first, neither by creating a system nor by somehow downloading it from the server.

To Reproduce
Download the source code of the PostScript Printer Application, build the Snap (it takes automatically care of using the current GIT snapshots of PAPPL and cups-filters), and install it. Connect one of the ~4000 supported PostScript printers. Then run

ps-printer-app -o log-level=debug server &
ps-printer-app -o log-level=debug autoadd

Your printer will get added, but with the "generic" driver and not the one specific to your printer model. You see it by the debug logging and also in the state file (/tmp/snap.ps-printer-app/tmp/ps_printer_app.state).

ps-printer-app drivers

shows that your printer deserves something better.
Do not try to determine the driver selected by the web interface, some of the recent PAPPL commits seems to have broken the media and default options parts (another issue report to come here).

Expected behavior
When calling

ps-printer-app autoadd

PAPPL should do one of the following three things to make "autoadd" work correctly:

1. Create a system, as ps-printer-app drivers does, then do the autoadd as before
2. Add a new function to PAPPL's server IPP to allow a client to download the driver list, then let ps-printer-app autoadd download the driver list before doing the autoadd as before
3. Add a new function to PAPPL's server IPP to simply accept an "autoadd" command, then let ps-printer-app autoadd send this command and the server does the actual process of auto-adding completely

I prefer (3) here as with ~4000 supported printers building the driver list takes several seconds. The server has the list readily available and so simply triggering auto-adding on the server would be the fastest, most efficient, and least memory-consuming.

And once adding such an "autoadd" command to the server's IPP interface, add "drivers", too instead of the client having to build the driver list separately.

And please do not tell me to build the driver list in the main() function before calling papplMainloop() as then I cannot log the driver list build process (issue #42).

System Information:

• Ubuntu, Focal Fossa 20.04 to build Snaps, problem occurs on both 20.04 and 20.10.
• PAPPL, cups-filters, and ps-printer-app are current GIT snapshots.

[michaelrsweet]

First, there is an IPP operation to get the list of drivers - Get-System-Attributes (IPP_OP_GET_SYSTEM_ATTRIBUTES) which returns the "smi2699-device-command-supported" attribute.

That said, the only thing that seems to need the list of drivers is your auto-add callback. The PAPPL code just sends a Create-Printer (IPP_OP_CREATE_PRINTER) request with the named driver, so as long as the driver is known to the server it will accept the request.

So it sounds more like you need to use the "data" pointer to hold the state information (including printer driver list) and have a function that is used by both the autoadd callback and server callback to create that driver list.