Regarding this issue, I agree 110% with Randy. One should think
twice (or more) times before considering handling multiple operations
due to the state ramifications.
Perhaps we should try answering Randy's (paraphrased) question:
"Why would a single operation per transaction be undesirable?"
Can anyone state any serious limitations?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
Date: Fri, 17 Jan 1997 08:25:56 -0800
From: Randy Turner <rturner at sharplabs.com>
MIME-Version: 1.0
To: rdebry at us.ibm.com
CC: ipp at pwg.org
Subject: Re: IPP> IPP Requirements Scenarios
Content-Transfer-Encoding: 7bit
rdebry at us.ibm.com wrote:
>> Classification:
> Prologue:
> Epilogue:
>> The following notes are in response to Jay's comments
>> 1) You suggested replacing PUSH and PULL with
>> The protocol must support these sources of client print data
> - print data is a file
> - print data is being generated on the fly by an application
> - print data is referenced by a URL
>> Answer: don't have a problem in stating the requirement this way. However,
> I'm not sure that we want to place getting a referenced file outside of the
> scope of IPP v1.0. I'd like some other comments on this.
>> 2) With respect to the first print job submission scenario you asked,
> "has it been decided that a single IPP transaction can contain more
> than one type of request?"
> Answer: Herriot, Isaacson, Hastings and I agreed on this in early
> discussions of the first IPP draft.
If you have a protocol wherein multiple operations are specified, each
with a "state" dependency on the previous operation (meaning that the
sequence of operations is part of the overall "stateful" request) then
this could complicate things considerably; meaning, you might have to
include some type of two-phase commit operation to verify that all of
the operations in a particular transaction complete or none at all.
This may not have implications now if we have a very limited
transaction/request set, but we will no doubt be extending this in the
future. I'm not sure why a single request per transaction would be
overly limiting in a first implementation of IPP.
Randy
----- End Included Message -----