Scott,
Thanks for replying to my message. I changed the subject line to perhaps
better reflect this thread. (The subject used to be something like
"MOD - Suggestion: add RequiredResources call...")
> > Model A: client ---> printer
> >
> > Model B: client ---> spooling server ---> printer
> > ...
> >
> > Seems like we had better come to grips with the possibility where IPP
> > should only attempt to address "Model B" above; then, as hardware
> > technology decreases in price, allow desktop printers to catch up.
> >
> > ...
> >
> > That is, let IPP address the "client ---> spooling server" portion of
> > the model, and develop a cheap, simple, and fast protocol to deal with
> > the "spooling server ---> printer" side of the model.
>> I was under the assumption that most everyone was focused on model B with a
> desire to not do anything explicit to preclude model A. I hope that this
> assumption is still valid. We need to define a job submission and control
> protocol that works for model B. If someday, someone happens to implement
> IPP directly within the output device (printer) which has a network
> interface card, then so much the better, but we do not force that in order
> for IPP to be successful. At that time, the model really becomes a single
> logical/architectural model:
I reread that last paragraph several times, but still remain confused
about whether you agree or disagree with my statements. Your last
sentences seem to agree with my suggestion that we should let printers
catch up in hardware capabilities in the future, and not worry about
low-end printers today for IPP. And yet, your first statements says
that the IPP group desires to "not do anything explicit to preclude
Model A."
As I mentioned, too many times we hear comments like "we can't do that
feature/approach, since low-end printers can't support it"...and hence,
we either eliminate the feature, or alter our approach due to this
constraint.
As a result, we seem to be moving in a direction that complicates the
protocol due to the constraints found in low-end printers.
Scott, perhaps you (and others) can help me out with what we here at
Underscore believe is a critical environmental issue surrounding IPP:
IPP seems to put forth the public notion that it will provide "printing
from anywhere on the Internet to any printer accessible on the
Internet." The various usage scenarios described in the Requirements
document revolve around these target environments (ie, the environment
surrounding the target printer):
- Pay-for-Print (aka, "Kinko's", etc)
- Printers used as virtual fax machines
- Uniform access to geographically dispersed printers in an organization
For the sake of simplicity, let's ignore for a moment those issues
surrounding security viz a viz access to the printer by the client.
The question is: Doesn't the IPP group believe that all such printers
would be front-ended by some sort of spooling system?
In our experience, Enterprise-level customers shun direct
client-to-printer operation (despite our previous attempts to convince
them otherwise). Why is this? The answer usually revolves around job
queuing, both for managing visibility of jobs, and to effect a degree
of fairness (eg, FIFO).
Does this jive with others' experiences? (I'd really like to hear from
others on this question.)
If you believe this is true, that all such printers are front-ended by
spooling services, then perhaps now you can see my concerns regarding
how the IPP design is being skewed by the lack of capabilities for
low-end printers.
> As to "Why?" do we need to even address model A at all in our thoughts and
> decisions: There are implementations today (in the Novell environments
> specifically) where the "server" is embedded in the "printer". In this
> case the "server" is not a "spooling server" but a "print server". The
> embedded print server uses a file server for actual disk space, but all
> status, control, queries, and events are realized through the embedded
> "server" (or model A). Therefore, since model A does exist in today's
> market, we must address it.
With all due respect (as you are a Novell printing systems architect ;-),
the NetWare PSERVER model is not exactly "Model A" as I had drawn. True,
status requests are sent to the embedded PSERVER, but that PSERVER (by
definition) uses a front-end spooler (NetWare QMS), right?
So, instead of Model A (shown as):
client ---> printer
The PSERVER environment is really:
client ---> spooling server <--- printer (with embedded PSERVER)
The only difference between the PSERVER model and Model B is that the
printer initiates communications between the spooling server and itself
(unlike Model B, in which the spooling server initiates the communications
with the printer).
Is this characterization true in your opinion?
> Having said that, I agree with you that I do not want IPP (v1.0) to become
> "all things to all peole with all devices by mid 1997". We should continue
> to focus on Model B and allow for hardware and other issues to help realize
> model B in within the output device (what you call model A).
Again, I think we need to start talking about "minimum printer implementation"
when we reach for various design alternatives for IPP.
> Also, I am interested in how you would apply real quantitative requirements
> to "cheap, simple, and fast" when you suggest a protocol to deal with the
> "spooling server ---> printer" side of the model? I am assuming that you
> are refering to the fact that as IPP is currently shaping up, IPP would not
> satisfy "cheap, simple, and fast"? I am also assuming that you are refering
> to an earlier email you osted about IPP protocol issues and suggestions to
> which I have not responded nor have I seen any other responses.
This topic is certainly worthy of a separate thread. I have not thought
about hard and fast metrics (in terms of numbers and rates, etc), however
few characterizations of "cheap, simple and fast" could be:
- Separate channels for control and data, ala FTP; when the data is
transmitted as a singular stream, then parsing time decreases
*dramatically* (potentially to zero).
- A single control channel utilized for the entire job submission;
a single channel precludes the need for state management, where
the printer has to maintain all kinds of state until the job is
fully submitted.
- A simple control channel framing protocol, easily implementable on
any platform, including very low-end embedded varieties.
How does this sound to you (and others)?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------