Subject: IPP>MOD more new operations?

From: [email-masked] (Robert Herriot)
Date: Thu, 12 Jun 1997 19:34:19 -0700

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

---

From: Randy Turner <[email-masked]>
Date: Thu, 12 Jun 1997 20:07:08 -0700

I think its an interesting idea, something akin to what I was
thinking about when I was using multiple URLs and create-job was
just a very simple object creation thing.

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