Roger K Debry wrote:
> Randy Turner wrote:
>> You are not considering the other advantages of the 'CreateJob'
> operation. The 'Validate' option only validates a set of
> attributes against what a particular object supports. It
> has no relationship to a job. Meaning that just because
> you send a 'Validate' request, does not necessarily mean
> that a print job is next in the sequence.
>> RKD> No, but it might be.
>> The 'CreateJob' not only validates attributes but also
> determines whether or not resources can be applied NOW
> to processing a job with these requirements.
>> RKD> This must mean that upon receiving a CreateJob, the
> RKD> Printer promises to maintain the state it was in with
> RKD> respect to requested resources until the print job
> RKD> is complete. Is this agreed?
Yes, to some degree, its possible that the server has locked down one or
moreresources to process this job.
> RKD> Does a client send CreateJob, assuming that if resources are
> RKD> not ready that the Printer will schedule the job accordingly,
> RKD> i.e. schedule all jobs waiting for A4 paper to print when A4
> RKD> paper is loaded, or does a client keep "pinging" the Printer
> RKD> with CreateJobs until it finds the resources are ready, then
> RKD> consummates the print job by sending the data?
It depends upon the type of 'resource' that may or may not be available.
In your example, you specify media as the resource in question (A4).
This
is only one of numerous possible types of resources. The response to a
'CreateJob' operation (and the clients reaction to this response) is
really
dependent upon the type of resource allocation problem that might occur,
as specified by the clients explicit or implicit job requirements.
> RKD> If we believe that the first is the preferred method for
> RKD> handling jobs waiting for resources then I claim that just
> RKD> using the PrintJob operation works as well as CreateJob and
> RKD> SendDocument since I don't care if the resources are actually
> RKD> ready NOW or not (and I doubt that I want to keep "pinging"
> RKD> the Printer to find out).
An out of resources condition is definitely going to happen, and
yes,implementations will have to incorporate retries (much like LPD does
today)
in order to see that the job is printed.
> Also, 'CreateJob'
> returns the URI for the job object created immediately so you have
> some
> way to either do a 'GetAttributes'
> or a 'Cancel' on the job if either one of these operations is
> required.
>> RKD> Doesn't PrintJob return a URI? If not why doesn't it?
Yes, 'PrintJob' does return a URI, but only after all of your job data
has been
transferred. Over the internet, this is completely non-deterministic.
Randy
> If you're looking to delete operations, 'Validate' would go before
> 'CreateJob' IMHO.