Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!lupine!hansen!djm
From: djm@hansen.NCD.COM (Dave Mackie)
Newsgroups: comp.windows.x
Subject: Re: printing at X terminals
Message-ID: <876@lupine.NCD.COM>
Date: 19 Jul 90 05:05:52 GMT
References: <63035B33DC3FC0AEAA@fccc.edu>
Sender: news@NCD.COM
Reply-To: djm@hansen.NCD.COM (Dave Mackie)
Organization: Network Computing Devices, Inc.
Lines: 92


As a vendor of X terminals, I'd like to contribute our experiences 
here at NCD to the discussion about printers attached to X terminals.
This is not meant to be an advertisment, it just happens that the work
I do is sold for a profit ;-)

After discussion amongst ourselves, and with the MIT X Consortium folks
we implemented a transparent serial I/O daemon to our X terminals that
is independent of the X server. The idea here is that the best protocol
is no protocol. This functionality acts like a 1 port terminal server
in transparent mode, i.e. no knowledge of any protocol other the network
transport and the RS-232 parameters. Currently, the serial I/O daemon
accepts connections over either TCP or DECnet, just like the X server.
It then transfers data bi-directionally, until one side or the other
hangs up. The only special case is if the network hangs up first, the
serial daemon guarantees that the data in the RS-232 queue is written
out to the device.  On the host side, we've created a sample filter
for the BSD print spooler that connects up to our serial I/O daemon 
and bi-directionally transfers data. A simpler networking program would 
be hard to find. We've been using this arrangement to do printing for 
the past several months for the entire company to Apple LaserWriters, 
and more recently HP LaserJets. This scheme allows us to deal with
all the complexity of formatting, routing, and spooling print jobs
on general purpose computers that have the appropriate tools.

Here are a few of the reasons that we took this approach over some 
of the alternate schemes that have been mentioned so far (I'm 
paraphrasing them here):

> Use the "universal" BSD lpr protocol.

Well as others have pointed out it's not universal, my product needs to
talk to VMS machines as well as UNIX machines, both BSD and System V based
(yours does too, probably). 

In addition, the lpr protocol is meant to be used between print spoolers. 
Well, my X terminal doesn't have any local disk for print spooling. Yes, 
I've got NFS support, but it's just plain silly to get the X terminal 
involved with a three party file transfer.  My idea of distributing 
computing is that one should put the work on the machine best equipped 
to do that work. Pring spooling belongs on general-purpose computers with 
disks.

And the kicker, who says it's a printer at the other end of the RS-232
cable? We already have customers who are hooking up bar code readers,
data tablets, and terminals! (GASP! You should have been suspcious when
I mentioned 1 port terminal servers ;-)


> Use a simple I/O connection just added in as an X extension.

Well, I believe we all agree that we need a garden hose. I bought
a generic, no-brand one, and you want to buy one made by Brand X.
They both have identical functionality, yours just has a logo printed
on it. If you want to make this a standard, please do, but let's not
force it to have an X on it. I'll even volunteer to write the RFC!
I would have the opportunity to be known as the author of the
shortest RFC in history!

A potential technical objection to this approach is that currently when
one goes an XGrabServer(), all clients except the one that did the grab
don't get any service from the X server. Well, when my window manager
puts up a wire-frame to query my desires regarding placement of a new
window, I don't want my printer to grind to a halt. Oh, well, the serial
I/O clients/sockets don't count in the server grab you say. In the immortal
words of Bill the Cat, "AAACK, THPTTT!"


> All I really want is to be able to dump my screen or window to my attached
> printer.

Well, I really can't cram format converters for every printer control language
known into your X terminal, and dynamically trying to link in just the one
you need is also a mess. This is another example of a task best suited to
a host computer.


> I want the printer port to have the same security as the X server.

Well, that's what we give you with our implementation. Does this need
to be standardized?  There isn't much standardization today with
regards to security, perhaps the advent of Kerberos will change that,
but in the mean time this seems like an unlikely spot to start a 
standardization effort.


Hope this is useful,


						Dave Mackie
						Network Computing Devices
						djm@ncd.com