... snip ...
>> 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> This seems pretty loose. If a positive reponse to CreateJob
RKD> means the resources can be applied NOW (as you suggest in your
RKD> initial email) then the resources better be locked down.
RKD> If it means it is possible, to some degree, etc ...
RKD> then a positive repnsese only means that a job object
RKD> is created and waiting for job data. It means nothing in
RKD> terms of being able to print NOW.
> 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> Help me by giving some other examples where the response
RKD> might be different. I'd like to understand this better.
> 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.
RKD> Will we really expect to see clients retry while waiting
RKD> for a resource to become available. This implies that
RKD> they understand that the resource is supported and
RKD> will become available reasonably soon (as opposed to
RKD> sometime next week). Does LPD really do this?