On 2022-06-20 at 08:59, Brian wrote: > On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote: > >> On 2022-06-19 at 15:47, Brian wrote: >>> You (or the OP) would have to say what is meant by "delete". >>> CUPS essentially *discover* printers. It is why it exists. Is >>> that not wanted? >> >> I understand the reason for CUPS' existence to be, not >> *discovering printers*, but *facilitating the ability to print*. >> That could involve discovering printers and presenting them as >> available, or it could involve only presenting as available a list >> of printers that have been entered into CUPS or otherwise set up in >> CUPS by some more manual means. (Among perhaps other >> possibilities.) > > The ability to print to an IPP printer involves discovering its URI. > CUPS gets the URI via avahi-daemon whether it is an on-demand or > manual queue. But that discovery doesn't have to be done by CUPS; once the URI is known, it should be possible for CUPS to simply accept the URI and work with it from then on, without discovery entering into the picture. >> Certainly at my workplace I understand that our Macs use CUPS for >> (network) printing, but at least at one point in our history >> (within the past decade), we had to go in and define each printer >> by IP address in CUPS on each Mac (or on the central machine which >> would be replicated to the others). > > Setting up a manual queue for a moden printer is still available > but is unnecessary. 'lpstat -e' showves every printer on a subnet and > they should (barring bugs) appear in an application's print dialog > without any intervention. The thing is, though, sometimes this is *undesirable*. Going back to my workplace as an example, we have one subnet per building per floor, and one printer per classroom; we want the computers in each room to be able to see and print to the printer from that classroom, *only*. Having the ones from the other classrooms show up in the applications' print dialog would be a problem. The set of printers which are discoverable on the network, and the set of printers which are available to applications as print destinations, should not have to be the same thing; the former should be generated on demand whenever discovery is performed, and the latter should be maintained locally. It should be possible to populate the latter list from the former, selectively, but this should not *have* to happen - much less always happen automatically in all cases. >> I can certainly see it as being reasonable to want to be able to >> have CUPS perform printer discovery *on request*, and manually >> choose which of the discovered printers to add to the list of ones >> that will be remembered and shown as available when printing, but >> not have CUPS run discovery *automatically* and *automatically* add >> every discovered printer to that list. (I don't know with any >> confidence whether CUPS does the latter; I don't run it in enough >> environments with enough different available printers to have been >> able to make an assessment. However, I do have the impression that >> it may.) > > You can control whether Avahi browses for printers or not but cannt > make it selective in its browsing. DNS-SD is an all-or-nothing > public service discovery protocol. Perhaps think of the display > screens at airports. That's just about discovery, though. I'm talking about what's done with the discovered information. It sounds to me as if it's being said that CUPS takes the discovered information and automatically puts every discovered printer into the list of printers that will be made available in the print dialog (or equivalent). That should not be the only option. It should also be possible to run discovery, manually select zero or more printers from the set discovered, and add *just those printers* to the list of those that will be shown in the print dialog (It should also be possible to add printers to that list manually, without running discovery, if you know the necessary information.) The result would be being able to be sure that the list of printers available in the print dialog will only change if someone manually modifies it, rather than changing automatically if the set of printers discoverable on the network changes. As far as I can tell, that's entirely a matter for CUPS, since CUPS is the software which would be maintaining such a list and providing such a list to the applications which need to print. If that behavior is possible, it must be CUPS that is providing it. If it is not possible, then by the nature of CUPS' purpose and role (that of middleman between applications and printers), it must be CUPS that is at fault for not providing it. > I beleive filtering of a printer list using LDAP is something being > considered for inclusion in a future CUPS. Why should LDAP need to be involved? Unless you're using an external print server to get the printer list from (in which case things become in some ways simpler and in other ways considerably more complicated), the list of printers that applications should see is local, and should be able to be maintained locally without bringing external things such as LDAP into the picture. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature