On Mon 20 Jun 2022, at 23:50, Gareth Evans <donots...@fastmail.fm> wrote: > 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
Though duplicating a "printer" (which I had come to consider a queue) in system-config-printer results in another PPD file in /etc/cups/ppd/, so I guess there's one queue per "printer representation with settings".
