But given where we are right now, I don't think there's enough
advantage in doing this to fatten up the protocol with more
operations. We just added two, which on reflection we probably
could have used attributes to accomplish but I understand the
rationale. I think at this point we should just flesh out what
we have and if what we have doesn't cut it with the overall
IPP requirements then we start fattening it up some more or
re-think our requirements.
Its not that what you're proposing couldn't be accomplished with
our current set of operations, it would just be a little more
bulky to pull it off. And ultimately, I'm not sure if the future
IPP world will be interactive or batch-driven. All I can do is
look at how systems work today (batch) and attempt to model them.
Randy
Robert Herriot wrote:
>
> 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
>