IPP> HTTP transport for IPP

[Robert Herriot]

> From rturner at sharplabs.com Thu Apr 10 13:30:20 1997
> 
> 
> 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.


I am concerned that the 3-URL solution will have hidden costs that we
haven't discovered, and I am not sure I see the flexibility or
scalability advantages.  I would expect the same piece of hardware to
handle all three URL's in 99% of all printer systems. This problem
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.


Having 3 URLs means that we have to decide which to return with each
operation.  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.


Bob Herriot