On Mon 20 Jun 2022, at 23:31, Gareth Evans <donots...@fastmail.fm> wrote: > 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/ ... and queues from other reachable CUPS instances ... > 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
