I have looked a little more closely at our current model approach to IPP
and I am not happy. :-(
We started off with the assumption that we would build IPP as a simpler
subset of DPA, taking into consideration some lessons that we have learned.
One of the lessons that I have learned, is that we messed up about objects
when we defined DPA.
Objects were introduced in DPA as an afterthought and does not really
follow architectural rules for object oriented design. One of my hopes was
that we would do a better job of this as we set out to design IPP as a
subset of DPA.
My impression of our current "model" design is that we have done most of
the thinking from the bottom up, concentrating on how we could select a
reasonable subset of attributes and to focus on how we could further
simplify the attributes that remains, plus adding in a few new ones for
good measure. Although some discussion has been held on modeling issues,
my feeling is that we have never questioned the IPP architecture, but just
tried to do some simplification of the current DPA approach.
I now want us to take a step back and consider that although IPP version 1
will have a more limited set of capabilities than DPA, we still have to pay
attention that we get a foundation on which we can expand in future
versions. The best way of insuring this is, in my view, to apply a better,
object oriented architecture right from the start and start looking at the
design also from a top down perspective.
I am not trying to make things more complex than they are currently planned
to be, but would like to see a better structure in how we design them.
The two areas in which I think we could do better are in defining objects,
and in selecting the right level of operations:
Object
=3D=3D=3D=3D=3D=3D
I think that we have got too far in our simplification efforts when we came
up with the solution that we did not need a Document object.
I would like to re-introduce the Document as a separate object for the
following reasons:
=B7 We have already decided that we need to have document level attributes
that override corresponding job level attributes. The current solution to
mark such attributes with an adornment, I find really messy, not only from
an object orientation perspective, but also from a syntax perspective.
=B7 The argument that we should not define documents as objects, because we
do not have any operations on documents in version 1, does not make sense
to me. As soon as we want to start adding more functionality to IPP in
future versions, the first thing we are going to need is operations that
can work on individual documents. A reminder is that DPA has in effect
baked several operations into one with its Print operation, one of which
works with documents.
=B7 The monolithic design that we currently have for the IPP Print operation
does not give us a lot of flexibility for the future, which is why I
suggest that we should define operations for documents already in IPP
version 1.
Scott has informed me that the MOD group has already accepted to define
Document as an object, it is not yet fully reflected in the working
document, so this is not really an issue.
Operations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I would like to see operations that are related to the IPP objects. My
assumption is that we have three main objects in IPP version 1 - Printer,
Job, and Document.
Here are the operations that I would like to see:
=B7 Get Printer Attributes
This would be used to find out about printer capabilities, and possibly
status, before submitting a Job.=20
The printer capabilities could be cashed, so this operation does not need
to be made for every print request.
=B7 Send Job Attributes
Used to initiate a new Job. It would contain all the attributes needed to
validate if the job can be done (although you can still run into problems
when document data is passed later). There would be an attribute stating
the number of documents in the Job, or an indication that it is a Job of
indeterminate length, where the number is not known when printing starts.
The client would receive a response, confirming if the job can be done or
not (with error codes) and a job-id is returned if accepted.=20
=B7 Send Document and Document Attributes
This operation would be used to send one document, with its Document
Attributes, if any. It would contain the job-id, so the Printer knows to
which Job it belongs. Alternatively, one Document Reference could be sent,
with its Document Attributes, if any. The server would return succes or
error (with error codes).
=B7 Send End-of-Job Message
This is a very simple operation, that just signals to the Printer that a
Job of indeterminate length has finished sending all the data for that Job.
It would not be used for other Jobs, and would not need to be supported by
printers that cannot handle Jobs of indeterminable lenght.
=B7 Cancel Job
Operation to delete a Job. As default, also deletes the associated
Documents. (In a future version of IPP we may want to allow for documents
to be changed or deleted in separate operations.)
=B7 Get Job Attributes
This operation is used to check up on a Job=92s current attribute settings,
as well as the Job status.
(May also include some Printer status attributes, which are necessary to
explain Job status).
=B7 Send Job Notification (probably realized on a different transfer=
protocol)
This operation would send success or failure notifications from the server
to the client (and possibly others, such as the operator or administrator,
or an intended recipient for the Job.
=B7 Send Printer Notification (probably realized on a different transfer
protocol)
This is intended to signal problems with the Printer (may be due to
problems on the device). It can be sent to the operator (or the end-user
if there is no dedicated operator).
I assume that IPP operations defined in the model document can be combined
when sent over a particular transfer protocol, but I have more difficulty
in seeing how to split up model level operations into several operations in
the transfer protocol.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com