I believe that we should try as hard as we can to hold the line on any new
invention on IPP and press on to get
what we have done crisply written, agreed upon and through the standards
process. If the interactive operations
Bob proposes have some value then we can add them to version 2, but I'd rather
not spend the energy debating
that issue when we there are more pressng problems to be agreed upon.
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 06/13/97 05:30
AM ---------------------------
ipp-owner @ pwg.org
06/12/97 08:42 PM
Please respond to ipp-owner at pwg.org @ internet
To: ipp @ pwg.org @ internet
cc:
Subject: IPP>MOD more new operations?
At the moment we have two ways to print jobs, one that does it one operation
and one that does it in pieces.
But when I look at this from the simple API point of view, I realize that both
of these solutions take the "batch" point of view for print job submission.
In the batch model the client submits a collection of attributes and the
printer either says "yes" or "no" with a collection of attributes that
caused it to say no.
An alternate "interactive" model is for the client initially to ask the
printer to create a job without specifying any attributes
(CreateJobStub below). The printer returns a job URI and job template
attributes to display on a GUI. When a user changes a value in a GUI,
the client performs an operation (ChangeJobStub below) with the job URI
that changes the attribute on the printer. With each change, the
printer says yes or no. Thus the client knows before accepting the GUI
whether the print job is OK. The SendDocument operation terminates the
sequence of change operations.
The new operations would be:
CreateJobStub (to a Printer URI): the printer creates a job stub with
each job attribute set to the Printer's default value. The Printer then
returns a job URI and all the jobTemplate attributes (i.e. those which
specify the printer default values and their potential values).
ChangeJobStub (to a Job URI): the printer receives one attribute (name
and value). If the change is allowed, the printer performs the change
and returns success; otherwise it doesn't make the change and returns
failure. Issue: should more than one attribute be allowed for this
operation. If so do all have to succeed for any change to occur?
Comments?
Bob Herriot