Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  printing at X terminals
Message-ID: <9007160604.AA18198@Larry.McRCIM.McGill.EDU>
Date: 16 Jul 90 06:04:07 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 75

>> Primo: a standard [for network printing] already exists.  It's
>> called lpr.
> lpr is an operating-system-specific standard.  That's no standard at
> all.

lpr the program is operating system specific.  lpr the network protocol
is not; any machine capable of supporting TCP connections should be
able to speak the network protocol used by lpr.  The only OS-specific
part I see is that it uses BSD's "privileged port" notion, which does
not prevent its use in this case.

But if that really bothers you, well, there are other standards
available[%].  I believe Imagen has printers that sit directly on
Ethernet networks; they must speak a protocol of the sort we're looking
for here.

>> Secundo: even so, that's no excuse for making X handle something
>>   inappropriate to it.
> Printing protocol is entirely appropriate to X - X provides multiple
> transport layers, plus built-in security mechanisms.

All that means is that using X to do printing is appropriate from the
point of view of doing printing.  My point is that it is inappropriate
from the point of view of X.

> Its[sic] a natural for providing the pipeline to a local printer.

I'd much rather use something else (such as lpr), so that when the X
server is not working (eg, not running) the printer is still available.

>> If I happen to have a disk attached to my X box, is that a reason to
>> make the X protocol also support disk access?  Really now.
> Disk I/O is not a terminal issue.  Local printing is.

I can't see how communicating with a printer attached to the box on
your desk is any more a "terminal issue" than communicating with a disk
attached to the same box.

In a mail exchange with another person, I came to the conclusion that I
mis-phrased my claim.  X is not "standardizing the software interface
to display/keyboard/mouse sets"; it's "standardizing the software
interface to the common types of display/keyboard/mouse sets".  For
example, X fails utterly to support a vector display - but vector
displays are far, far rarer than raster displays.

> What if you had LEDs on your X keyboard?  Should X be extended to
> send messages to the LEDs?

No; no extension is needed.  Look up the XKeyboardControl structure
used by XChangeKeyboardControl().  But see my next paragraph of reply.

> Should X be extended to accept input from a data tablet?  YES!  Allow
> X to print too!

It slices, it dices, it even displays windows!  I don't think X should
be a do-everything protocol.  Something should be added to X only when
necessary, which typically means that arbitrarion of access to it must
(or should) depend on the window system.  Keyboard input is an example
of what I mean: keyboard input is conceptually independent of windows,
except for the notion of where the keystrokes go (X calls it "keyboard
focus").  IMO, keyboard LED control does not belong in X, at least not
in its present form, because nothing is available with the current way
that's not available under the paradigm where the LED control is split
off into a separate server.  Similarly, I feel XBell shouldn't be part
of X.  (If X LED control were elaborated so that each focus window has
its own set of LED bits, then merging it into the X server would (IMO)
be justified.)

And (needless to say, by now) I think printing does not belong as part
of an X server.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu