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.
> From jkm at underscore.com Fri Mar 21 09:24:58 1997
>> 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?
>> ----- 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