Path: utzoo!attcan!uunet!husc6!yale!mintaka!bloom-beacon!FCCC.EDU!STODOLA From: STODOLA@FCCC.EDU (Bob Stodola) Newsgroups: comp.windows.x Subject: Re: printing at X terminals Message-ID: <63035B33DC3FC0AEAA@fccc.edu> Date: 17 Jul 90 19:50:00 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 66 Comments on the rws/wood dialog... >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 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. I agree. I think support in the X-protocol for the "workstation" -- not in the sense of a computer with disk drives and other concerns, but the thing that sits on the users' desk -- is entirely proper. I agree that anything which reduces wiring (hard or soft) is a plus. If I put an X-terminal on my desk, it seems to me that a local I/O port is an obvious adjunct to the "workstation". The fact that so many people have local printers (as well as other devices) certainly speaks to its practical uses. Why wire separately for it? The comparison with a local disk drive is not reasonable -- the physical proximity of a disk drive is rarely an issue -- the physical proximity of printers often is. The fact is that there is a demand for local device access through X workstations. That demand is being addressed in an ad hoc fashion by vendors. Whether addressed by an X protocol extension or some other way, I think it appropriate that the X-community address the issue. Ducking it by declaring it a non-issue for the user interface doesn't make it go away, it merely leaves it in many different - and sometimes less qualified - hands. >> 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. Frankly, I think its a pretty reasonable conjecture. >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. I agree. If it can't be an X-extension, I would encourage the X-community to at least serve as a focus for a standard which X-terminal vendors can use for this purpose. I don't think saying "use lpr" really addresses this problem very well.