CUPS: end-user usability issues

[pipitas]

m.stonebank at surrey.ac.uk wrote:

> Michael Sweet wrote:
> 
>> With CUPS, each client has local queues which hold the job for that
>> system; the local jobs are forwarded to a server for printing when
>> that server is ready for them.  This method ensures that print files
>> are not lost if a server goes down, and allows us to provide failsafe
>> and load-balanced printing "for free".
> 
> Sorry, but this is a bogus philosophy.
> 
> In a business/educational/realworld environment, people don't want their
> print job sitting on their local box for x number of hours when the print
> server is down.  They want their printout NOW. 

This truely is the case in *some* or even *most* environments.

But there are others too (and some are my customers), which are 
no less business/educational/realworld-like than yours. Here
people want to initiate the job and get on with their work.
They dont necessarily care if it is printed in 5 minutes or in
60. They may not even ever see the printout they initiated, which
may occur in a different floor, building, or country altogether.

Sorry to disturb your picture of the "one and only true" printing 
world scenario here...

> They want to see the state 
> of the print server to see if its up, if it has a large queue. 

They can do this with CUPS if they are interested.

> That way 
> if there is a problem, they can decide to print elsewhere.

They can do this with CUPS if they are interested.

> The state it is now, you print and wait and wonder.

No -- even now you can query local as well as remote CUPS
servers for the jobs they have queued. Please have look at
the man page and the "-h" parameter" for lpstat. (I am sure
you already know about the web interface too). -- Admittedly
this is not yet the most userfriendly way to get the info.
In an ideal world a user would type (or click the analog
action in a GUI) "where is my last printjob now?" and get
the answer: "it was send off your workstation 7 minutes
ago to spool to printserver XYZ. XYZ forwarded it to server
ABC, where it is currently ranked as the 5th job to be printed
on printer 123".

So what are you doing to help implement such a user-friendly
printing system?

>> One side-effect of this architecture is that users won't see the
>> server queue state, however even if we changed lpq/lpstat to query
>> the remote server you still wouldn't have a true queue status since
>> the server queue will not show all of the jobs that are queued on
>> other clients at the same time!
> 
> 
> The idea of a print server is just that - IT is the print server. 
> Distributed print serving is no good if there is no way of checking the
> other clients in the distribution.

If you want one and only one centralized print server -- 
install one and only one centralized print server.

If you want things behave like LPRng -- use LPRng.

> --
> Michael Stonebank
> Senior Computer Officer
> University of Surrey

Cheers,
Kurt