> Our experience has indicated that within the Enterprise, all network
> printers must be front-ended by a spooling server; direct printing from
> a client system to a network is highly discouraged, or even forbidden.
>
> Does this experience match others' in the Enterprise? I'd really like
> to hear from other people on this question, either publicly or privately.
As background, so you'll know where my comments are coming from,
Northlake makes printer interface software for the Digital OpenVMS
environment. It may seem we're a little off the beaten path, but
these systems (and our software) see service on both client and server
side of our customers' printing strategies, on heterogeneous networks,
departmental to enterprise scales, low-end to production printing, so we
cover a fair amount of ground.
A couple comments:
1. No, I see no such consistency in our customers. Many have chosen
server architectures, but many prefer less centralized approaches.
In support of this, I would point out all the multi-protocol network
printer interfaces out there -- they're there because customers
insisted on them, and what they do is make the printer accessible to
multiple systems on some good-sized networks.
2. When you talk about a preference for server-based as opposed to
decentralized configurations, you ought to ask why. A big part
of the answer is that today's clients and printers often behave
unreliably; also, they have problems with sharing. Interposing a
server system helps with these problems, but at considerable cost.
Thing is, better printing protocols would help a lot, too. I'd hate
to give up on this as a goal for IPP.
3. Assuming your printer is capable of spooling is no panacea. For
example, just recently we spent a lot of time with one of our
customer tracking down an intermittent failure (happened only at
night with the lights out, you know) sending print jobs to a UNIX
system acting as a print server -- it was running out of disk space
when too many jobs queued up. I'd say if you're careful to consider
problematic scenarios in your protocol design, not just the happy
case, the spooled printer isn't that much better off than the
non-spooled one.
Jay, what I'm reading into your comments is the notion that assuming a
spooled server simplifies that protocol requirements. I question how
true this is. The example of storage constraints (client or server
side) may be typical -- a robust protocol has to deal with similar issues
either way.
In our environment, we've been very successful with decentralized
printing configurations. Admittedly, we have the advantage of a relatively
robust, capable client system, and we tend to gloss over the issue of
fair sharing of the printer. When they can be made to work reliably,
these configurations offer advantages in flexibility and cost. I'd like
to see IPP make them work better, not bypass them.
:: David Kellerman Northlake Software 503-228-3383
:: david_kellerman@nls.com Portland, Oregon fax 503-228-5662