Our initial deployment and rationale for IPP is primarily focused
on the end-user scenario. Administration and Management of the
IPP printing service is outside the scope of my document. The
proposal I did does not explicit preclude extensions to allow
administrators to find out URLs for subsequent management requests,
but again, its out of scope.
I'm hoping that my proposal is not evaluated based on requirements
that are out of scope...but I do understand the need for
administration and management and if we want to take that up in
the initial version of IPP, I would be happy to revise the
document to reflect these new requirements.
Concerning Bob's desire to achieve 1 URL, I agree that it would
be simpler. But in analyzing the cost difference (development and
design) between returning 3 URLs and 1 URL, the flexibility and
scalability of the additional URLs was well worth the code. And
from a big picture standpoint, I don't consider the effort at
understanding 1 URL as opposed to 3 URLs noticeable.
Its not that you couldn't do it with 1 URL, it does simplify the
"create-job" response, but it potentially complicates the
design of IPP when obtaining the other URLs, if you need them.
Randy
Robert Herriot wrote:
>> > From harryl at us.ibm.com Wed Apr 9 15:45:34 1997
>> > 1. The idea of returning 3 URL (Data, Status, Modify) upon job submission is an
> > excellent means of facilitating end-user job status and ability to cancel one's
> > job. However, sometimes there may be an administrative application that wants
> > to modify jobs. Unless this application had also received the Modify URL, it
> > would be unable to cancel or modify jobs in the "IPP queue".
> >
> > I think this might be accomplished by a QUERY to the "root" IPP service URL
> > which would return a list of currently active and pending print jobs. It would
> > be crucial that, included with this list would be the Modify URLs. Note there
> > may need to be some authentication regarding who gets these.
> >
> >
>> I think that I understand the reasons for having 3 URLs returned, but
> I still keep thinking that 1 job URL would be better and simpler.
>> Harry's example above reminds me of this problem when he mentions that
> the list of jobs returned should include at least two job URLs for each job
> (i.e. the query url and the modify url).
>> We may also decide to add more URLs later and have different URLs for
> cancel and for modify, giving us 4 job urls.
>> Does anyone else think that we should strive for one job URL, and have
> the operation specified in the message, or am I alone?
>> Bob Herriot
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com