On Mon 20 Jun 2022 at 19:49:18 +0100, Brian wrote: Please forget about this mai. I pressed the wrong key. Never done that before!
> On Mon 20 Jun 2022 at 12:34:19 -0400, The Wanderer wrote: > > > On 2022-06-20 at 12:01, Brian wrote: > > > > > "...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. > > > > > 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. > > > > > 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*. > > > > > 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.) >
