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
Attachment:
signature.asc
Description: OpenPGP digital signature