IPP> Job Templates (Retry) [I like getting rid of Job

IPP> Job Templates (Retry) [I like getting rid of Job

IPP> Job Templates (Retry) [I like getting rid of Job

Tom Hastings hastings at cp10.es.xerox.com
Wed Dec 18 15:18:20 EST 1996


At 19:05 12/17/96 PST, Robert Herriot wrote:


>I have tried to keep the fan-in concept supported by job template/default
>values as a simple way of initializing a job in different ways for what
>is fundamentally the same output device via all associated Printers. 
>
>I suggest that we not try to solve the problem of limiting feature
>access (as Tom suggests) via different Printers for a particular output
>device during this project. That mechanism is very different from
>simple initialization of values, and it adds to the complexity.
>


I think that the above is a good summary of the issue.


by having fan-in of Printer objects.  As far as the user is concerned
there are just Printer objects that the Directory contains and that
the end-user can submit to.  The end-user can tell whether a Printer
is (1) the only Printer for an output device, (2) fanning-in to an 
output device or (3) fanning-in to another Printer object.


In fact, the confusion that I see is with having fan-in of job templates
because our current draft has it both ways that a URL on the Print operation
can specify either a Printer or a Job Template.  By allowing fan-in
only of Printer objects, the whole concept of Job Templates disappears
from the end-user's view.  


When we do go to IPP 2.0, we can revisit the idea of implementing the
defaulting mechanism as an object that multiple printers can share, as
you suggest that may be a help to some administrators, though it adds
the complication of objects referring to other objects and dangling references,
i.e., Printer objects referring to Job Template objects.  Adding Job Templates
to IPP 2.0 will not change the simple end-users view; adding Job Template
objects will only help (or hurt) an Administrators job of specifying defaults
for a set of Printer objects.


I also think that the ability to have different access control and policies
for the same output device to be a very important feature for some
situations.  Only fan-in of Printer objects will permit different policies
for the same output device.  Fan-in of Job Templates will only get different
defaults.  Defaults cannot be used to enforce policy; defaults are valid
values for end-users to supply, but the user can change them to any other
supported value that the policy specifies.  If there can only be one Printer
object for an output device, there can only be one policy for that output 
device.


Tom



More information about the Ipp mailing list