IPP> HTTP transport for IPP

IPP> HTTP transport for IPP

IPP> HTTP transport for IPP

Robert Herriot Robert.Herriot at Eng.Sun.COM
Thu Apr 10 22:13:11 EDT 1997


> From rturner at sharplabs.com Thu Apr 10 18:49:32 1997
> 
> > This seems like a datastructure problem where it is usually better to return
> > a pointer to the root of the structure than to return several
> > components at the next level.
> 
> This statement implies that there might be a 'hierarchy' represented by
> the URLs that are returned. There could be, but then again they may be
> distinct. Basically, the multiple URL method allows you to construct the
> 99% case (whatever it turns out to be), and it also allows you to divide
> up the chores of the print system, according to either:


I think that part of the issue here is whether there is a "root" job URL
from which other job URL's can be obtained, and if so, whether the
specialized job URLs are optimizations that save a trip to the server.
--------------------
 
> Having more than one URL allows a system designer to distribute 
> functionality, rather than having all clients experiencing a bottleneck
> by hammering away at a single URL for all operations.


I would expect this problem to solved by distributing the printers 
across many servers rather than distributing the URL for each job.
-----------------------------
> 
> There's no decision here if I understand you statement. We specify
> in the standard which URLs to return (logically). Or, if you mean that
> we have to architect code that has to make this decision, it would
> also have to make the same decision about which resource to call on
> if you embed the operations in the pipe to a single URL.


I mean that the standard would have to specify this.
--------------------------------
> 
>   For example, the GetJobs operations probably doesn't return
> > the SendJob URL -- maybe I'm wrong, but that is the problem.  In
> > addition, the 3-URL solution may lead to our needing to define a
> > mechanism/attribute for get one type of job URL from another, e.g. the
> > modify job URL from the query URL.
> 
> The only operation in my proposal that returns URL strings is the
> "Create-Job" operation. 


What does GetJobs return?  I assume that a client that wants to do
a GetAttributes or CancelJob would not necessarily be the same client
that did the Create-Job and thus could only get the URL's via a GetJobs
query.


> > Bob Herriot
> 
> 



More information about the Ipp mailing list