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