Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!aplcomm!capd.jhuapl.edu!waltrip From: waltrip@capd.jhuapl.edu Newsgroups: comp.sys.next Subject: Re: (Ne)X(T) Terminals---a hot product idea? Message-ID: <1991Apr29.115156.1@capd.jhuapl.edu> Date: 29 Apr 91 16:51:56 GMT References: <1991Apr25.084827.1475@math.ucla.edu> <1991Apr26.193131.10122@wimsey.bc.ca> <15108@darkstar.ucsc.edu> <1991Apr28.044626.11746@menudo.uh.edu> Sender: news@aplcomm.JHUAPL.EDU Organization: CAPVAX, JHU/APL Lines: 58 In article <1991Apr28.044626.11746@menudo.uh.edu>, matt@karazm.math.uh.edu (Matt Emerson) writes: > In article <15108@darkstar.ucsc.edu> isbell@ucscf.UCSC.EDU (Art Isbell) writes: >> >>In article <1991Apr26.193131.10122@wimsey.bc.ca> jchin@wimsey.bc.ca (Joseph Chin) writes: >>more network traffic than X jobs. Has anyone run the same application under X >>and DPS (there are a few that have been ported to both, I think) and compared >>network efficiency? I think this is a really important issue. I had always >>assumed that part of X's braindeadedness (!) relative to DPS was its >>voluminous >>network protocol. But maybe DPS ain't so good either. Can anyone comment? > > While we're speaking of the bandwidth issue, I'd like to point out that > Sun's NeWS product addressed this issue very neatly. The problem with X and > DPS over the network is that whenever you want to draw something (say a > dialog box) you have to send a lot of instructions over the wire each time you > need to draw it. If the dialog box is complex, this could munch up a lot of > bandwidth. With NeWS, you say, OK, I'm going to be drawing this dialog box a > lot; so you write a PostScript program to draw it and handle interaction > with it and then you download it to the server (where the screen is) ONLY > ONE TIME. Afterwards, whenever you need to draw the box, you send a single > little message from your client program to invoke the PostScript routine > over on the server. I think this is a superb idea. The key is that the > server is dynamically extensible -- essentially, you can add new "primitives" > as you go along. I suspect you could probably optimize a DPS application for low- bandwidth networks also, don't you think? Problem is: it's probably something you don't want to have to think about as a developer (I know my plate is already full when it comes to NeXTstep/PostScript/Mach development issues to try to come to terms with). The real problem here is that this country is letting itself lag behind the technology curve in telecommunications. We should have a minimum of 56kbaud switched digital service as available in every home and office by now as a standard voice line (and as cheap). We telecomm users need an effective lobbying group. The original part of this thread addressed cheap DPS terminals. I believe the price/performance curve is rapidly making this true. The new ACE consortium (DEC/Intel/Microsoft/et al) will be turning out commodity boxes with OSF/1 on a MIPS R4000 and high res monitors. An (almost) ideal box (only thing missing is a DPS controller but, with the R4000, it's hardly necessary) for NeXTstep. These will be cheap. It will be hard to produce anything cheaper. If NeXT gets on board, we should see cheap boxes and cheap applications (both NeXTstep and Motif--maybe even Windows). c.f.waltrip Internet: Opinions expressed are my own. > > Just FYI... > -- > Matt Emerson > matt@karazm.math.uh.edu