Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
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.)
Reply to: