I am the developer of PLP/LPRng/LsPRng, which are UNIX based
print spoolers. I have had to fight with interoperatiblity, different
standards, and am only too aware of what can go wrong.
I know that you folks have been working hard on this - there is an incredible amount
of details covered, hashed out, and some really clever things done in the
Model standard - some of which I plan to steal and use in LPRng...
I mean 'use as a basis for enhancement of operations'...
I would like to make some suggestions that I think will improve the model,
as well as make life simpler for implementation and interaction.
I think that the underlying model of the printer that is proposed in the
Model document is too simple, and is in contradiction with the various attributes
and values that you propose. It tries to avoid complexity, while at the
same time the various details express information about components and
interactions not currently part of the model.
I would like to suggest that the following modified model be used. Note that this
is NOT a rejection of your model, but an enhancement - I like a lot of the
ideas, and am trying to make them easier to explain/specify.
Printer
+-----------------
<Interface URL>|
-------------> | Input Queueing --------------------- ***************
| ------------------ ** | active job handler| --- physical device
|**| queue | / --------------------- **************
| ------------------
<Interface URL>| \ --------------------- ***************
-------------> | | active job handler| --- physical device
| --------------------- ***************
| Administrator
+--------------------
First, I like the idea of URL based address access to the printer - simple, elegant.
Note that you may have several different URLs for the same printer, depending
on the format required, transport, etc. This is accomodated by the multiple
Printer Interface URLs shown above. In this case, we might as well call them
Printer Interface URLs.
The Printer (well, actually it is a print server) will have a 'master queue'
into which all incoming jobs are put. These jobs priority/requirements will be
sorted, matched, etc., and then will be placed in the input queue or
rejected.
The active job handlers are reponsible for identifying a job in the queue and
then feeding to the physical device. The active job handler will remove a job
from the queue, process it, and conditionally put it back in the queue
if required. Note that the input queue queue can have 0 length -
this means that the incoming job would be fed directly to the active job handler.
The Administrator is the component that sets up and manages the various
components.
This really does simplify the model and the attributes.
For example, a Printer might not have a job queue in the sense of
copying jobs, but could have 'pending connections'.
You would get attributes of each of the various components now:
Administrator - the configuration,
status, queues, and physical devices.
Note: you could have a default URL for the adminstrator,
which would now have a list of the Interface URLs available
Queue - numbers of jobs in queue, etc.
The queue information would consist of a list of URLs corresponding
to the jobs. You could now find out detailed job status by
querying for the job URL in the queue.
Active job handler - the current status of the active job, and the
physical device.
Physical Device - the capabilities of the physical device.
Patrick Powell