Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI to help drivers emit IPP job submission input parameters

From: Patrick Powell <[email-masked]>
Date: Sun, 4 May 1997 08:39:13 -0700 (PDT)

# >
# >If not, why not design the protocol so that resource requirements can
# >be attached to the *end* of the print request?

# Been there, done that.  Don't want to repeat such mistakes.

I have also been there, done that, and I agree:
  - Put the format/options/job control/etc
    first
  - have a negotiation protocol, not just 'blast the job and see
    if it prints' protocol

# >
# >OTOH, I personally think that it would probably be better in version
# >1.0 to take the "do or die approach": let the human or driver negotiate
# >some resources (like A4 paper) up front, and then the job either prints
# >or crashes. Just make sure the error report is right..... There's no
# >way I can think of where one can negotiate on *every* resource one
# >can think of - for instance, some *ancient* PostScript printers allowed
# >you to put 68000 machine code into PostScript files; do you want to
# >include negotiation on the CPU type in the printer?

# Certainly not.

There is a fine dividing line on this problem.  I think that there
should be some ability to 'find' printer characteristics,
but some of these should not be 'hardwired' into the spec,
i.e. - format.

The current approach seems to be very very sane- have 'resources/attributes'
with fixed 'key/tag' values,  and then have some 'text' based ones
which can have a 'non-fixed' text format.  This allows you the best
of both worlds.  You could put 'manufacutuers information' in the text
format.

# >
# >KISS.....

# We agree.  The hard part is deciding for which party to make it simple:
# the client or the server/printer.  Requiring job parameters to be first is a
# little harder for the client (than allowing the client to put them last),
# but make a hugh simplication for the server/printer.  So the net is much
# simpler to require job parameters to precede document data.

I want to have the server as simple as possible.  That way the chances of
having it done 'RIGHT' and 'UNIFORMLY' and 'CONSISTENTLY' by multi-leben-dozen
different manufacturers goes up tremendously.

The less things to mess up the more likely it will get done right.

Patrick Powell

# >
# >                 Harald A