Another problem with dynamic binding is that an end-user cannot see
what is fixed (by the client) and what is floating (with respect to
printer defaults). I don't want to suggest another adornment to tell
the user which is which. In addition,if the client forwards the job to
another printer, then the dynamic attributes will potentially change.
Bob Herriot
> From jkm at underscore.com Fri Mar 21 09:24:58 1997
>> Roger,
>> You might view it as "an implementation choice"...but what about the
> poor user?
>> Specifically, if the system administrator changes the job defaults
> between the time the job is submitted and the time the job starts being
> processed for printing (ie, when you would do dynamic binding), then
> the job may very well not be processed the way the user expected.
>> Recall that the user can list the target printer's default attributes
> prior to submission, and then submit the job, believing that the
> defaults are acceptable.
>> How would you guard against (ie, protect the user from) this situation?
>> ...jay
>> ----- Begin Included Message -----
>> From: Roger K Debry <rdebry at us.ibm.com>
>> It actually seems simpler to me to "dynamically" bind to defaults.
> Otherwise it seems that I have to "fill-in" the blanks for every job
> when I spool it. Dynmaically binding allows me to not touch the job
> attributes when the job is spooled but "fill in" the blanks when the
> job actually starts to print. This would seem to be an implementation
> choice.
>