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