On Mon 20 Jun 2022, at 17:34, The Wanderer <wande...@fastmail.fm> wrote: > On 2022-06-20 at 12:01, Brian wrote: > >> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: >> >>> On 2022-06-20 at 08:59, Brian wrote: > >>>> 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. >> >> "...once the URIis known"? What mechaism does that? Incidentally, a >> URI is required to query a printer for its attributes. > > Any of a number of mechanisms. > > CUPS could run discovery once, then either A: present the discovered URI > with a prompt for whether to add it to its local list of known printers > or B: add it to that list automatically, and then in either case not run > discovery again until something asks it to. > > The user could run discovery manually (e.g. from the command line), then > enter the discovered URI into CUPS. > > The user could look at another computer where the URI is already present > in CUPS, and copy that across to the computer at hand. > > I could probably come up with more options if I thought about it for > long enough. > >>>> 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*. >> >> It is possible that upstream CUPS would agree. The intention is to >> do something about it eventually. > > Depending on what the "something" is, that could be a very positive > development! > >>> 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. >> >> DNS-SD doesn't traverse subnets. > > Yes, but we don't have one subnet per classroom, we have one subnet per > floor, with multiple classrooms per floor. > >>>> 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.) >> >> That's certainly possible at present. > > I figured, and seemed to recall, but did not want to assume. > >>> 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. >> >> Other would see the automatic change as a definite plus. > > And in some cases so would I! But not in others. And my interpretation > of Gene's original complaint, as you quoted it, would suggest that he is > in a case where he also would not. > > That's why whether or not this discovery-and-updating process is > performed automatically should be *configurable*. > >>>> 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. >> >> My understanding of LDAP is very limited. All I know is that CUPS >> will eshew simple filtering. It has been tried, and didn't work. > > I don't even know why filtering would be involved. You're not starting > with a longer list and filtering it to show only a subset; you're > starting with an empty list, populating it (either manually, or > automatically but only on demand) from a longer one, storing the > resulting list, and later showing it on demand. > > Or, at least, that's the way it *should* work. > > If there's a reason why filtering needs to be involved, given that "two > separate lists" model, I'd be interested in seeing that reason > clarified. > > (I can see why it would be useful in a model which says that the list > which is available to applications is always updated automatically from > the list generated by discovery; in that context you'd need some way to > tell the system which things from the discovered list should be included > or excluded from the made-available list. But since that shouldn't be > the only behavior, filtering shouldn't be the starting point for > thinking about this.) > > -- > 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 > > > Attachments: > * signature.asc
My understanding is that /queues/ appear in application dialogs and seem to be what is at issue. I can't test this as my combination of cups + printer isn't working as expected, but from /etc/cups/cups-browsed.conf: "# Set CreateIPPPrinterQueues to "No" to not auto-create print queues # for IPP network printers. [...] # cups-browsed by default creates local print queues for each shared # CUPS print queue which it discovers on remote machines in the local # network(s). Set CreateRemoteCUPSPrinterQueues to "No" if you do not # want cups-browsed to do this. For example you can set cups-browsed # to only create queues for IPP network printers setting # CreateIPPPrinterQueues not to "No" and CreateRemoteCUPSPrinterQueues # to "No"." If cups or avahi still provide a list of /printers/ when setting up /queues/ manually, doesn't this provide a mechanism to achieve "list-on-demand" with queues otherwise hidden to applications and system-config-printer? Best wishes, Gareth
