IPP Mail Archive: Re: IPP> HTTP transport for IPP

Re: IPP> HTTP transport for IPP

Randy Turner (rturner@sharplabs.com)
Thu, 10 Apr 1997 18:41:58 -0700

Robert Herriot wrote:
>
> > From rturner@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.

The same piece of hardware might indeed handle all 3 URLs, but there
are several other parts of a URL besides the 'hostname' part that
could change depending upon the request., i.e., PortNumber, job-specific
URL parameters, Protocol Scheme, etc.

> 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:

1. Different host machines
2. Different processes/tasks running on one particular host machine
3. Different processes/tasks, possibly running different protocols, on
one or more host machines.
4. Different processes/tasks, running different security domains, either
one one or more than one host machine.
5. etc. etc. etc.

The overhead for 1 versus 3 URLs is minimal and it allows the print
system
designer to optimize his/her resources as necessary.

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.

>
> Having 3 URLs means that we have to decide which to return with each
> operation.

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.

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.

Another way to look at this problem is that we could state that the
"Create-Job" operation returns "up to 3 URLs". And we specify if there
are fewer URLs returned, exactly what this means. (i.e., if only one
URL is returned, then this URL serves all operations for this print
service).

Randy

>
> Bob Herriot

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
rturner@sharplabs.com