# 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