jmw9681@USAV01.GLAXO.COM ("J. Michael Word") (07/13/90)
From: USA::JMW9681 12-JUL-1990 15:04:39.03 To: USAV01::WINS%"wood%lavc3.dnet@smithkline.com" CC: JMW9681 Subj: RE: FWD: Printing on X-terminals Thanks for forwarding this info to me. I definitely agree with you and Bob: it sounds fishy to users to be told that they something useful and easy on the older equipment is now harder and very much non-standard on their expensive new equipment. Simply put, local printing is generally understood to be a terminal issue and work to increase the usefulness of the terminal should not reduce capibilities. I suppose it is easier if some OTHER standards committee has to figure out the problem but just who would that be? I vote local printing is a terminal issue and X is standardizing the software interface to terminals. Mike
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/14/90)
> I suppose it is easier if some OTHER standards committee has to > figure out the problem but just who would that be? Primo: a standard already exists. It's called lpr. Secundo: even so, that's no excuse for making X handle something inappropriate to it. > I vote local printing is a terminal issue and X is standardizing the > software interface to terminals. I doubt it will be settled by vote :-) X is standardizing the software interface to display/keyboard/mouse sets, not to printers. 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. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (07/15/90)
>Primo: a standard already exists. It's called lpr. Well, "lpr" may or may not be the right protocol to use to talk to an X terminal with a printer attached, but... >Secundo: even so, that's no excuse for making X handle something > inappropriate to it. ...I agree 1000% with the second point. If it's convenient for the X terminal to talk "lpr" (i.e., if it's capable of taking several jobs and queuing them up somehow, which means it may want to either have a local disk or a remotely-mounted file system) it's a better choice. Otherwise, some other protocol could be imagined; I seem to remember that Imagen printers have some protocol that lets you connect them to an Ethernet and open TCP connections to some port and blat a print job at them (they may refuse a connection, or something, if they're busy printing), and Apple Laserwriters can certainly work over Appletalk, so the idea of sending output to a printer over a network is demonstrably implementable. You could have a backend for your spooler (whether "lpr"-based or not) that opened a connection to the printer rather than opening a serial or parallel port to it (such as Columbia's CAP has for Appletalk printers, for example). No need to drag X into it, just because X happens to be *ONE* of the services that the device to which the printer is attached offers.
david@twg.com (David S. Herron) (07/19/90)
In article <9007140606.AA03669@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: >Primo: a standard already exists. It's called lpr. Ugh.. if only it were a good standard :-) >I doubt it will be settled by vote :-) > >X is standardizing the software interface to display/keyboard/mouse >sets, not to printers. 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. Ok.. heading off on a tangent here. Sometime Real Soon Now I will start writing a User Agent for sending/receiving X.400 mail. One of the target environments is X based workstations. Among the types of output to be supported are moving pictures (animations) and sound. I know how to do moving pictures, page flipping possibly with some kind of compression. It won't work very well considering it's gotta go over the network ... But how 'bout sound? That's not a display, keyboard, or mouse thing. But it needs to be supported. Actually the job's harder than that since the other targets are PeeCee's and Mac's ... fortunately I don't do those ports. If we take your attitude sound'll never be supported. If we take your attitude printing'll never be supported. Both are things which people want to do at their work area. Both arguably belong to the model. I don't have a solution, just dredging up the issue. (BTW, I have a very vague memory of seeing a development effort on supporting sound in the X environment. I'd be interested in knowing what's going on if anything..) -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/20/90)
[ I think this issue has been about done to death, but David effectively points out that I didn't make my position entirely clear. ] > Ok.. heading off on a tangent here. > Sometime Real Soon Now I will start writing [a program that wants to > "display" sound]. > But how 'bout sound? That's not a display, keyboard, or mouse thing. > But it needs to be supported. > If we take your attitude sound'll never be supported. > If we take your attitude printing'll never be supported. Not at all. I see I need to clarify: I do not oppose local printing and local sound; what I oppose is using the X framework to support local printing or local sound. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (07/21/90)
>If we take your attitude sound'll never be supported. > >If we take your attitude printing'll never be supported. If we take his attitude, sound and printing will never be supported by extensions to the X protocol. Whether this means they'll never be supported at all is another issue - one about which people can probably speculate until they're blue in the face, but which isn't likely to be resolved by any hard facts until either 1) somebody invents the "Y Sound System, Version 1" and its related protocol, and the "Z Network Terminal Printing System, Version 1" and its related protocol or 2) a fair bit of time goes by and nobody invents either one. Perhaps those who want the ability to do sound, printing, etc. at network terminals and remote workstations and don't particularly have any religious feelings that they belong in X should get together and do 1), and render the whole discussion moot, or unsuccessfully attempt to do 1) and demonstrate that their failure was inevitable due to restrictions that would have been absent had they implemented them as X extensions.