# The LPD protocol (aka RFC 1179) was NOT designed in a vacuum. It was
# designed as part and parcel of the LPD daemon environment; that environment
# expected to FIRST spool all components of the submitted job (one or more
# data files, followed by one control file). So, if you have the luxury
# of spooling all these components, then of course you can "reverse the order".
Umm... you are going to hate this, but actually LPR came first, RFC1179
was simply documenting LPR. This is the same thing as RIP - RIP was
first, then the RIP RFC came much later; note that the RFC had some
'do this as I say, not as I do' type things in it.
# In the category of "Fun Things to Know and Forget": in our travels,
# only OS/2 2.1 sends the control file before the data file(s). I
wonder # how many LPD daemon systems mess up as a result of this...
Ummm... I think you mean 'the broken vendor implementation of OS/2's
print spooler'... There are 2nd party spoolers that do it in EITHER
order, selectable by a run time switch.
Note that the BSD based LPR implementations usually send control files
first, the ones supplied with SYS III, send data files first, and the
SYS VR4 seem to do what they damn well please from release to release.
In the PC world, I have seen both - there is a drop in LPR client for
most Windows 3.1 WINSOCK support packages, and I have seen both data
first or job first from different packages.
I have also noted that some printer manufacturers, when the implement
LPD servers in their systems, IGNORE the control file and use
'autosense' methods to determine what the file contents are.
I remember fighting with a XXX (censored) printer, and trying to print
a students 'malformed postscript' file so I could take it away and look
at it and the printer kept locking up with 'postscript stack... '
messages printed on it.
Hey! Why should we be surprised? Given so much broken software out
there, most people try to be as accomodating as possible in what they
accept, and as restricted as possible in what they send.
Patrick Powell
# ...jay