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