No subject

# >
# >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