On 02/18/2016 16:33, Chris Bennett wrote:
On Thu, Feb 18, 2016 at 04:10:06PM -0500, gwes wrote:
.....
They don't do dynamic autoconfiguration.
In an industrial environment autoconfiguration can be very bad.
(examples like directing confidential output somewhere unexpected)
I haven't looked at the code from LPRng, but it provides options to use
a pool of printers for certain jobs to be sent to.
I think that case is rare but should be considered.
....
The only function I can think of that lpr doesn't have is
the capability to request a forms change and wait until
it has been done. That could be an entirely separate subsystem
invoked by lpr.
When you say forms change, are you talking about paper size/type
changing or something else?
Forms change can mean size, material, preprinted forms, ribbon,
type chain, etc.. pretty much anything beyond "change input tray".
One more function that I can think of is scheduled access
dept. A from 4:00am to 11:00am, dept. B from 11:01 to 14:00, etc.
I've been in many places where many wifi printers were wide open and in
several adjacent businesses.
Ouch!
The case for retiring lpr et al really depends on your use model.
One size fits all could be difficult.
How much access and use control?
How much initial setup?
How much per-user setup?
How many printers and per-printer setup?
As you mention, wifi printers are common. Without access control,
they short-circuit any administration. Then anyone with the
password can do anything. A piece of javascript and a browser
would give users as much control as is possible.
So... wired printers - again, if they are open on the net,
access control is difficult or impossible. A very few
I've heard of have per-IP access control.
Either of these two cases really are "submit" and "monitor
for done". The only central administration that's possible
is to recommend which printer someone is to use.
IMnotsoHO, lpr works fine for these cases. The user
selects which printer to use and then queues the job.
Automatic printer discovery could be a boon or a
disaster. Better reporting of printer errors
and daemons not running and easy restart would be good.
Wired printers on a host have two cases.
The simple subcase: printer is a general resource
that happens to be connected to a machine that's
really someone's workstation, etc. Here, the biggest
problem is setting up a server daemon.
I think the previous cover 90% of use.
What improvements do these categories need?
Once you have multiple printers, things get complex.
It's probably one for businesses. Is there
any IT staff? The VAX/VMS print spooler probably has a lot of
the controls for this case. It assumes an operator.
My take: the interface to lpr, lpd, etc could be
cleaned up. For most uses, the functionality is adequate.
Adding a "find a printer" program would help.
The complex case, well, how much work do you
want to put in defining requirements?
None of this, of course, covers running out of paper
when all the stores are closed.
Geoff Steckel
