Roger K Debry wrote:
>> 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
>> ---
>> Actually, in a true client situation, the end-user
> never sees URLs, in fact, he doesn't even have to
> know the term 'URL'. And in the browser case, using
> multiple URL strings with CGI parameters as HTTP
> POST targets is the natural way to encode IPP
> operations.
>> RKD> Yes, a GUI can hide all of this complexity,
> RKD> but in other discussions we have recognized
> RKD> that there may be end users using a command
> RKD> line interface. How does a true client solve
> RKD> this problem for them?
There's really no difference, you would have multiple
command line applications that are IPP-operation
specific (similar to LPR and LPQ and LPRM), that all
start with queries to the root "URL".
>> ... snip ....
>> I would propose the same solution for any transport.
>> In my opinion, funneling everything through 1 URL
> is too monolithic a solution when we have the
> flexibility of URLs as object identifiers.
>> RKD> So, if we decided to go with a different URI scheme,
> RKD> such as IPP://xxxxx.xxxxx.xxxxx, without the underlying
> RKD> http services, then you would still propose multiple
> RKD> URLs for the job, based on the operation being
> RKD> performed?
Yes, but the 3 URLs I'm proposing are defined in a "macro"
way, meaning that they are "types" of URLs to which
different command sub-types may be issued via
application/ipp message types. Take for instance, the MODIFY
URL. This URL "IS" operation specific, meaning that it
handles MODIFY operations, but MODIFY in this sense is a
macro or higher-level way of thinking of this object. It
really says that this URL is used for any command to modify
the state of the job; so, it is logically specific to one
type of job access, but it is capable of handling many
types of IPP-specific sub-commands such as cancel, requeue,
re-prioritize, modify-attributes, etc. or whatever we come
up with.
>> RKD> I guess my simple mind finds it hard to grasp why
> RKD> we have one object, a print job, to which we give a
> RKD> different name, depending upon what action we
> RKD> are taking on that object.
Again, its not 1 URL for each specific action, its 1 URL
for each CLASS of actions you want to perform on the object.
Randy
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com