Oliver's notes of things to talk through at the mini printing summit on 11/24/2009

The client/service grid

The situation has become complex and nuanced enough that I think we need to walk through this, at least quickly, and consider the questions:

• Which are known to work?
• Which are known to not work? Is that okay?
• Which should be discouraged (because of effort, complexity, etc.)? Is that okay?
• Which need to be explicitly tested because answers to the above questions are not known?
• For things that used to work but won't going forward, what business need are they addressing and can it be met some other way? How difficult will the transition be for clients?
• Have we made decisions on the fly that may need to be reversed or postponed? If so, what's the impact? What's the impact of not reversing?

If nothing else this information will be needed to inform the printing wizard Heather Anne is working on.

Functionality as we move into a CUPS world

Job control

• lpq, lprm, lpc, lpadmin
• web-based via cups.mit.edu
• web based via printers.mit.edu

What should our job control story be to the community? Given Oliver's new motto of "Do no worse" is there a chance we can make it at least as functional as the old model? Can we make it a little better?

Metrics

• We are currently collecting page count, job name, and user name information from CUPS.MIT.EDU via Virebo. Will this work via PRINTERS.MIT.EDU? In particular, what's up with page counts?
• Does PRINTERS.MIT.EDU position us any better for metrics requests that are probably "coming soon"? (Quotas, limits, overage charging, etc.?)
• Is an infrastructure transition now the right thing to do given that: at least three task forces are looking at student printing and MIT-wide printing; we don't have a lot of money to invest in printing infrastructure and we don't know future demands on it yet? Is it really mainly the "PDF->Postscript problem" and if so should we just fix that?

Documentation

• Expensive printing documentation in the clusters (SAVE project, ~$1000 total not counting labor); is it worth re-doing this? If not, are we taking a step back or is documentation no longer necessary because (printing) life is easier?
• Web pages and stock answers: who changes what?
• Printing "portal" page at http://ist.mit.edu/services/printing

Policies

• DUPLEX on by default for new accounts
  • Is it still?
  • Will there be gaps?
  • Is it still the right thing to do?
• DUPLEX on for cluster printers
  • Can CUPS do this?
  • Is it "safer" than with LPRng? (I.e. easily override-able for individual jobs?)
• Header pages off for specific
  • Printers
  • Jobs
  • User accounts
  • Can these be easily controlled under CUPS?
  • Can a default be set by printer? By a user?
• Stalled job timeouts
  • Can we expire stalled jobs on cluster printers? Risks? Notification needed? Reasonable timeouts? (DUSP/Architecture have some real-world user data here.)

Review 2007 SAVE student survey which contained policy questions on:

• Header pages
• DUPLEX
• Expiring stalled jobs

See also

• Statistics on printing