At 05:11 PM 7/16/97 -0700, Paul Moore wrote:
>This is to propose a change to the model based on reviewing the
>protocol.
>>At present the plan is that to cancel (for example) a job you send a
>cancel operation to the job's URL.
>>Bob Herroitt and I propose that this be changed: you send a cancel
>operation to the printer URL giving a JobId as a parameter.
>>This has the advantage that the client only needs to know one URL for
>all operations on a given printer.
>>This then carries through into GetJobs returning a set of Jobids instead
>of a set of Job URLs. A jobid is just an opaque token, the client should
>not attempt to use it except as a way of identifying a job back to the
>server.
>
Paul,
I am not too happy about this change. Going back to our earlier discussions,
before you got involved, we determined to use URIs to identify Jobs because
it gave us the flexibility to actually create the Jobs under a different
server name (on the same or a different host), which might be useful in some
bigger printing systems. Your solution seem to be optimized for the scenario
where you have a generic Web server in combination with a Printer in the same
host. Your solution seems to just complicate things a bit in scrnarios where
you have an embedded or dedicated HTTP server that only does printing.
In summary, I think your solution introduces new restrictions in our design,
which are not particularly desirable. Is there any other way that you can
solve your design problem?
Carl-Uno