zben@umd5.umd.edu (Ben Cranston) (03/08/90)
Back in 1986, when we had just bludgeoned our troglodyte management into
getting a few Mac Plusses, I was assigned
THE NETWORKING PROBLEM FROM HELL !! AEIII!!
"Make it so we can share a single LaserWriter between our Macintoshes and
our Unix machines..."
I'm sure some of you have been faced with this problem or a similar one
("Share between Macs and IBMs", "Share between VMS machines and Macs"...).
One of the two staff people who were doing networking at the time, and who
has now become a troglodyte manager in his own right, and being a TCP/IP
bigot, added another requirement:
"Do it with TCP/IP."
This was years before MacTCP.
Well, I can't claim any real great success. We used the "change the plug
AND flip the switch" scheme until we got a second LaserWriter, and to this
day one of them is on LocalTalk and the other is on a
serial-line/annex-box/TCP-IP linkup.
Just recently somebody posted a set of patches for printing 5.2 and 6.0 to:
* Always do command-F.
* Inhibit creating the Postscript file.
* Open ".BOut" as the file to be written.
This makes the Postscript come out the serial port, and this person
monitored the serial line from a Unix box and did the appropriate thing.
This started me thinking. What always held me back from really solving the
NPFH was being unable to separate the QuickDraw to Postscript translation
from the Printer Access Protocol over AppleTalk drive. I even looked at
replacing the PAP driver, but the NBPLookup code was in LaserWriter proper
and so would also have to be patched.
Suppose one were to take the posted patches, but instead of opening the
serial driver ".BOut" one were to open ".MyKlugedPrintDriver" instead?
Then one would write one's own device driver, which would do the network
interface stuff.
In my case I would open a TCP/IP connection to the selected host and stuff
the data down the wire with an appropriate protocol. The other, really
minor, factor was that we are MDQS bigots also, and the MDQS protcol
requires telling the remote side exactly how many characters you are going
to send before starting the send. This is not a problem when the data is in
a spool-space file and you have Unix's exact character counts, but it is
somewhat of a problem when you are generating the data on the fly. Knowing
how big print files sometimes get, I didn't want to buffer the whole file
in memory, and really didn't want to assume the existance of a hard disk to
buffer on. Somebody here is working on a follow-on protocol that allows
multiple "chunks" to be sent, each with its own length indication. So
I'd probably write this proposed beast to that standard.
This certainly looks like a workable approach, but I'm kind of afraid of
what the "System 7 From Hell" might do to it. If anybody has comments,
suggestions, and/or brickbats I'd sure like to hear them.
Please mail rather than posting.
Ben Cranston <zben@umd2.umd.edu>
Network Infrastructures Group
Computer Science Center
University of Maryland at College Park
--
"It's all about Power, it's all about Control
All the rest is lies for the credulous"
-- Man-in-the-street interview in Romania one week after Ceaucescu execution.