Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
I also prefer one URL!
Although admin functions are not part of the current version of IPP, we clearly
should not do something now that would make admin functions added later more
difficult.
I think that an end user ought to see and think about TWO objects, the printer
and the print job. That's simple and easy to understand. Presenting the user
with multiple URLs ( the underlying client system can't be guaranteed to
completely hide these from the user -- especially in the browser case) seems
absolutely wrong to me.
It ssems to me that Randy indicated that scalability was the main reason for
returning 3 URLs, but this seems an artifact of using HTTP and the way that a
web server works. If we did not use HTTP, would this still be Randy's
solution???
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 04/11/97 07:49
AM ---------------------------
ipp-owner @ pwg.org
04/10/97 01:20 PM
To: Harry Lewis/Boulder/IBM, ipp @ pwg.org at internet
cc:
Subject: Re: IPP> HTTP transport for IPP
> 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