Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker!bloom-beacon!SMITHKLINE.COM!wood%lavc3.dnet
From: wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163)
Newsgroups: comp.windows.x
Subject: Re: printing at X terminals
Message-ID: <9007171212.AA01273@smithkline.com>
Date: 17 Jul 90 12:12:11 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 79

>Since I haven't seen specifications for how vendors currently provide print
>service, it's hard to argue.  But I think the real question is: can it
>be made at least as simple, straightforward, and obvious, without going
>through X.  It seems clear to me that it can be.

It isn't as simple because the software for, say, lpr, is not easily
available on different OS's and different network transport layers.  It's
also not simple because the process of standardization is not being driven
centrally, so the terminal manufacturers do what they want.

A message from jcp@ciba-geigy.ch (Joseph C Pistritto) reminded me that
printing is not the only issue:

	In addition to printing, by the way, the other handy application we
	have is for doing RS-232 input, usually from authentication devices
	like card or barcode readers.  Once again, standardization, (and the
	ability for 'standard programs' like xterm to be able to use the
	device) would be handy.

To me, using the existing pipe provided by X for input/output to ports
on the terminal is esthetically clean.  The alternative is to run additional
"wiring" like lpr.  Viewed in a broader context than is generally appropriate
on this list, X devices are local input/output devices.  It seems artificial
to complicate their practical applications based on the concern that X is only
for graphics (at least in this case :-)).

>    The implementations of X terminal printing are
>    currently all different, are not secure, and don't run on all transport
>    layers supported by the server.

>All of which are orthogonal to the question of whether it should be done
>using an X extension.

This response frustrates me, because it doesn't show an appreciation for
the practical problems encountered by terminal manufacturers and users
who are trying to implement solutions on the fringes of the standards world
(and standards don't imply availability anyway!).
The practical issues are important too.  X could provide a standard for local
input/output.  An input/output extension for a simple byte-stream protocol
is all that's needed.

>Just because there once was a bad idea, we should perpetuate it?  Local
>printing through the terminal stream was forced on people because the
>terminal only supported a single connection.  X terminals do not suffer
>from this defect.

The only reason it was a bad idea was that local printing monopolized the
connection.  With the X pipeline, that is not a problem anymore.

>    The security  and access concerns of most users vis-a-vis
>    their terminal are the same  for their printer as for their terminals.

>I'd say that's a conjecture, rather than a fact.  But if you want the
>security of the printer to default to the security of the X server, fine
>with me.  I still don't see that it needs to be bundled as an X extension
>to achieve that.

It doesn't have to be, but the mechanism is already in place.

>    It doesn't print.

>And it shouldn't.  It still seems that the only argument that has really been
>put forward for making printing an X extension is the belief that the
>X Consortium could make a standard, and it isn't clear what other organization
>reasonably could.  Now that I've dispelled that myth :-) how about some good
>technical arguments?

The argument so far has revolved mostly around an idealization of X, which
I believe is (practically speaking) too limiting.  Local input/output to
printers and other devices from X terminals is desireable (I don't think
there's disagreement on that point).  The X pipeline provides transport,
security, and multiple connections to a local input/output device (the X
terminal/workstation).  Using this pipeline for input/output to local ports
is an elegant solution which requires no additional transport mechanisms,
and is analagous to using ethernet for differing types of network traffic.
I propose a simple extension to X for input/output.


- Bill					wood@smithkline.com