[cups.development] [RFE] STR #2844: Support for Wildcards in CUPS

[Jerome Alet]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

I'd like to submit the following proposal :

----------------------------------------------
  - Add a way for CUPS to accept wildcards, at the very least in printer
names, using a function similar to fnmatch (or fnmatch itself). This would
allow, for example, things like : 'lprm -P "hp*" -' to remove all print
jobs on all print queues whose name matches 'hp*'.
----------------------------------------------

There are several ways to do this, but all require that CUPS way of
authorizing lots of characters in print queues' names has to die, if the
characters that would be reserved for matching are actually allowed as
part of print queues' names. At least '*' and '?' should be allowed, but
full regexps would be better of course, limiting even more the range of
useable characters (this is why only '*' and '?' would be easier for
people to accept)

1st way :

  - Modify the CUPS scheduler in order for the 'printer-name' IPP
attribute, as well as all related attributes (e.g. device-uri) to be
decoded and matched against the list of available print queues. Pros : no
client side modification needed. Probably relatively straightforward to
implement. All CUPS clients immediately benefit from the change. Cons :
processing time, but simple matching even against thousands of print
queues should be fast on today's machines, and could also be cached. Some
existing print queues, probably a small few ones if any, have to be
renamed. The matching against list of available print queues' names could
be limited to the 'printer-name' attribute and only for certain operations
involving printer enumeration, but imagine the benefit of being able to do
: 'lp -d "hp*" somejob.ps' to print the same job to many printers
simultaneously...

2nd way : 

  - Modify all CUPS' client applications to first retrieve the list of
available print queues, then do the matching. Clearly this solution has
only drawbacks : processing time, network resources, benefit only to
modified clients, etc... etc... The only Pro is that the scheduler doesn't
need to be modified.

other ways :

  - ???

Any comment ?

I'm willing to help in coding or testing this if needed.

Link: http://www.cups.org/str.php?L2844
Version:  -feature