wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163) (07/16/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. lpr is an operating-system-specific standard. That's no standard at all. >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. Its a natural for providing the pipeline to a local printer. >> I vote local printing is a terminal issue and X is standardizing the >> software interface to terminals. Obvious! Just ask anyone who can't print anymore because of their fancy new X terminal. >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. Disk I/O is not a terminal issue. Local printing is. What if you had LEDs on your X keyboard? Should X be extended to send messages to the LEDs? Should X be extended to accept input from a data tablet? YES! Allow X to print too! Bill wood@smithkline.com Please CC replies to me, I'm not on the xpert mailing list.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/16/90)
>> 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
wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163) (07/16/90)
>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. There are a many ways to print to an X terminal's printer, but none of them are as simple, straightforward, and obvious as doing it through X. 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. This situation is not surprising. It is difficult for a terminal manufacturer to implement, say, lpr, on a VMS system. For one thing, very few VMS systems have TCP/IP. (I don't know of a terminal manufacturer who used lpr over tcp/ip either!) >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 the server isn't running on an x terminal, you're dead in the water. If you're on a workstation, use lpr to print. I'm not suggesting that the server monopolize the printer - the server could implement the printing extension using (local) lpr on a workstation. >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. Because local printing is something you do through your terminal connection. Always has been. The security and access concerns of most users vis-a-vis their terminal are the same for their printer as for their terminals. The printer is an extension of the terminal. >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. That's a nice distinction, but its not practical in this case. It doesn't print. > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu - Bill wood@smithkline.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/17/90)
There are a many ways to print to an X terminal's
printer, but none of them are as simple, straightforward, and obvious
as doing it through X.
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.
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.
Because local printing is something you do through your terminal connection.
Always has been.
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 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.
The printer is an extension of the terminal.
But not an extension of X.
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?wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163) (07/17/90)
>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
STODOLA@FCCC.EDU (Bob Stodola) (07/18/90)
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.
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/18/90)
> To me, using the existing pipe provided by X for input/output to > ports on the terminal is esthetically clean. And to me it isn't - so what? > Viewed in a broader context than is generally appropriate on this > list, X devices are local input/output devices. The argument seems to be arising from the disagreement between those who feel that X should be a workstation interface protocol and those who think it should be a window system protocol. >>> 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. (Which is perfectly true.) > 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. What are you waiting for? Write an input/output extension and make it available. That's how X came about, after all; nobody forced it on us. > I propose a simple extension to X for input/output. Well? So where is it? (I probably wouldn't use it; I don't think it belongs as a part of standard X. But I definitely welcome experimental additions.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
janssen@parc.xerox.com (Bill Janssen) (07/18/90)
In article <9007161432.AA02724@smithkline.com> Bill Wood writes:
Because local printing is something you do through your terminal connection.
Always has been.
Look, Bill, I worked for years on a VT241 with an attached dot-matrix
printer. I know what you're talking about. I understand the
convenience and the model. But it really is an ad-hoc kind of thing.
The 'right' thing to do is to put an Ethernet board in the printer,
and hook it up on to the Ethernet right next to the X terminal. Or if
the X terminal is on a serial line, run another one to the printer.
Now, if we're really talking about 'local' printing, I have no trouble
with putting a key on the X terminal that causes the printer to print
the current screen display.
Actually, if you really wanted to get ugly... Make the printer look
like a built-in client to the X terminal. Have a printing program on
the host that exchanges data with the printer "client" via a property
on the root window of the X terminal. This way the printer can get
its data via the standard X protocol, without problems. And the
X terminal vendors can fight about the right way to implement the
solution.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304janssen@parc.xerox.com (Bill Janssen) (07/18/90)
In article <63035B33DC3FC0AEAA@fccc.edu> STODOLA@FCCC.EDU (Bob Stodola) writes:
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.
An interesting position. But perhaps there should be a "workstation protocol",
of which the window system section would be X. Other sections of the protocol
could address other things which live on workstations.
"When all you've got is a hammer, everything looks like a nail..."
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304ral@hydra.Jpl.Nasa.Gov (Roger Lighty) (07/19/90)
In article <JANSSEN.90Jul17232251@holmes.parc.xerox.com> janssen@parc.xerox.com (Bill Janssen) writes: > |>In article <63035B33DC3FC0AEAA@fccc.edu>STODOLA@FCCC.EDU(Bob Stodola)writes: > |> I agree. I think support in the X-protocol for the "workstation" > |> ... >An interesting position. But perhaps there should be a "workstation protocol", ... > >"When all you've got is a hammer, everything looks like a nail..." I think this point has been made previously in the discussions about audio <4840@crltrx.crl.dec.com> (Jim Gettys) and Input Device Extensions <9006051941.AA01117@sol.uswest.com> (Bob Scheifler). X is not an everything protocol. It may be proper to use the X model and build a larger protocol of which X is the window statndard, 'H' is the audio standard, 'P' is the print interface standard,.... These then all support the 'Y terminal' protocol -- later replaced by Y(o). {:-{)} Roger Lighty ral@hydra.jpl.nasa.gov Jet Propulsion Lab. (818) 354-3525 ---- Of course these are my opinions, JPL's lawyers will not allow it to have any opinions.
djm@hansen.NCD.COM (Dave Mackie) (07/19/90)
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
jg@crl.dec.com (Jim Gettys) (07/19/90)
>>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. One "wires seperately for it" for long term software maintenance reasons. If two functions (to use two examples, file systems, and X display services) do not interact closely, then you should build seperate interfaces, so that as parts of the system grow, change, or are found unnecessary, you can change those parts of the system with out having problems with all the encumbering baggage. >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. This is an argument for people to get together and agree on standard interfaces. I have no problem with this argument. I have major problems with the conclusion you draw from the argument. The problem comes when you say "make it part of the X protocol" directly. Printing on attached serial devices (even if you believe these are rational, given network based printers these days...) has nothing to do with X. Make it a seperate protocol. An example of this is XDMCP, the display manager control protocol. Having X terminal manufacturers (those silly enough to have serial ports) get together and agree on a standard protocol for accessing those serial lines seems sensible to me. I suspect it can be as simple as "access this TCP port and start sending and reading bytes", and maybe another port for modem control commands. But making it an X extension seems like folly to me. KISS the server! - Jim Gettys
datri@convex.com (Anthony A. Datri) (07/20/90)
>The 'right' thing to do is to put an Ethernet board in the printer, >and hook it up on to the Ethernet right next to the X terminal. Or if >the X terminal is on a serial line, run another one to the printer. Ethernet would still be a high-cost transport for the cheap printers that are often used in such applications, and this only replaces the problem with a differnet problem, since there is no standard for how one communicates with an ethernettted printer. --
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/20/90)
[I'm behind on this topic, but this caught my eye.]
Having X terminal manufacturers (those silly enough to have serial ports)
It is not at all silly to have a serial port on an X terminal. I certainly
want to be able to sit at home with my X terminal, using the machines at
the office, and still be able to print files on the printer sitting next
to my X terminal, which is connected to the serial port. I just don't
want to use an X extension to print it.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/21/90)
>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. In this particular question I wasn't suggesting using lpr. Use whatever program you would use if you were using an X extension, but then just don't use an X extension. The code used by Xlib for different transports is really not very large, and hardly unique. Not at all difficult to replicate. Instead of calling XOpenDisplay, call OpenPrinter. The rest is identical (save for not using the X prefix :-). It's also not simple because the process of standardization is not being driven centrally, so the terminal manufacturers do what they want. I wasn't clear, I was asking a technical question. My fault. 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 :-)). It is precisely the slipping into a broader context that we disagree on. 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!). And this response frustrates me, because it doesn't show an appreciation for the practical problems encountered by a Director who is chartered with a specific mission and who wants to avoid stepping in sinkholes and wants to avoid moving into areas that others (e.g. formal standards bodies and other industry bodies) will view as outside our scope. These are "practical problems" too, and cannot be dismissed lightly. 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'm sure we could provide a standard, but the fact of that possibility doesn't make it right. The only reason it was a bad idea was that local printing monopolized the connection. No, I don't believe that's the reason. It was a bad idea because it fundamentally intertwined two things that were logically independent. 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. We don't see the analogy the same way. The way I look at your analogy, the IP protocol (assuming it came first) would be required to contain subcode space for any other transport protocol that you wanted to run on the same wire. Or the Telnet protocol (assuming it came first) would be required to contain subcode space for NFS and X. The ethernet running into my workstation contains multiple, independent application-layer protocols. The wire running into my X terminal should be treated no differently. I propose a simple extension to X for input/output. You are welcome to find a Consortium member to champion your cause, and you are welcome to become a Consortium member and champion it yourself.
meo@rsiatl.UUCP (Miles ONeal) (07/21/90)
I've missed a few days, so... Has Computoone/Princeton Graphics been mentioned in this regard? Have they gotten into the discussion? They even allow the x terminal's printer port to be used as a network remote printer. Talk about creeping featurism... -Miles
jordan@morgan.COM (Jordan Hayes) (07/23/90)
Robert Scheifler <rws@EXPO.LCS.MIT.EDU> writes:
I certainly want to be able to sit at home with my X terminal,
using the machines at the office, and still be able to print
files on the printer sitting next to my X terminal, which is
connected to the serial port. I just don't want to use an X
extension to print it.
Ah-hah! But, that serial port that connects you to your office doesn't
speak a general transport protocol, but rather a proprietary protocol
especially developed to do compression of the X protocol (admitedly not
designed for low-bandwidth environments) over your slow modem -- so all
there is is an X stream, no room for anything else.
I agree, it doesn't belong there. But what the heck? ;-) Unless you
want me to run two modems to the office, one for the dedicated X
stream, and one for a general purpose transport protocol link,
something needs to get sacrificed. For the ethernet environment, where
the X stream is already coming in via an general transport, the vendor
has no business hacking that into the X protocol ...
# "Do you want protocols that look nice, or protocols that work nice?"
# -- mike padilipsky
/jordanrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/23/90)
But, that serial port that connects you to your office doesn't
speak a general transport protocol, but rather a proprietary protocol
especially developed to do compression of the X protocol (admitedly not
designed for low-bandwidth environments) over your slow modem -- so all
there is is an X stream, no room for anything else.
You've made an assumption about whether the X terminal at home speaks
something general (e.g. TCP over SLIP) or something special-purpose
(e.g. NCD's Xremote protocol or GraphOn's protocol), and whether that
special-purpose protocol allows multiplexing. There is at present no
standard for a special-purpose protocol for doing X over slow serial
lines. If and when such an intermediary protocol were attempted to be
made standard, the issue of multiplexing the line for other purposes
(like printing) would surely be argued. It might even turn out to be
an "extension" of that special-purpose protocol, depending on how the
protocol was designed. But that's still not the same as making it an
X extension.
Unless you
want me to run two modems to the office, one for the dedicated X
stream, and one for a general purpose transport protocol link,
something needs to get sacrificed.
The only thing that needs to be sacrificed is the notion that everything
should be an X extension. :-)jg@crl.dec.com (Jim Gettys) (07/23/90)
Hmm.... I'm not sure I'd want my X terminal talking a proprietary protocol over the wire. Much better would be a version of SLIP or PTP (point to point protocol, which is replacing slip) with good header compression, and a X specific protocol compressor running over it. 'Cause I'd like to have other IP cognizant devices at home, like my workstation, laser printer, etc, all over the one modem.... Then a seperate TCP port seems like a trivial thing to do... Monopolizing my modem (and even more important, my home phone line) seems like a a terrible lose to me.... - Jim
janssen@parc.xerox.com (Bill Janssen) (07/24/90)
In article <9007222107.AA26600@s6.Morgan.COM> jordan@morgan.COM (Jordan Hayes) writes:
[...] so all
there is is an X stream, no room for anything else.
As I pointed out earlier, there is plenty of room in the X protocol
for arbitrary client-to-client sub-protocols. You can do local printing
over a pure X stream (no extensions) by adopting some client-to-client
conventions.
But your comment assumes an X-only stream, rather than a "remote workstation"
stream, which would support X as a subset. Why? Lots of people use SLIP as
the stream protocol, which allows you to run many task-specific sub-streams
on it.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304