Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!husc6!bloom-beacon!SUN.COM!dshr From: dshr@SUN.COM (David Rosenthal) Newsgroups: comp.windows.x Subject: Re: X Terminals & SLIP Message-ID: <8807142332.AA15613@devnull.sun.com> Date: 14 Jul 88 21:24:08 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 28 > Many of the points you make below are good, but there are a few corrections. > It seems to me that SLIP is the best thing we have at the moment, but that we > should look for better alternatives for the future. The point of the mail was to show people where the "better alternatives" were coming from and what the timescale was. People interested in getting a functional defacto standard for use with X terminals need to be in touch with the IETF effort. > I think 4.3BSD SLIP is close to a defacto standard, though certainly there are > incompatible versions, and this is a problem. Compression is definitely a > problem, though it can be handled in hardware (for instance Telebit > Trailblazers do hardware data compression if requested). It's not clear that > compression is really that big a win during interactive use of X. It will > probably only help during transfers of large bitmaps or significant other > amounts of data. The handshake will slow things down in interactive response. 4.3BSD SLIP isn't a good enough defacto standard for X terminals to use, and incompatible versions are more than just "a problem" if you're shipping machines with software in ROM. The compression that matters is not Telebit-type data compression, but header compression. The headers can be many times the size of the data. To repeat, if you are planning to ship X terminals that work over the phone with generic systems, rather than just one type of proprietary box, you need to be in touch with the IETF effort. David.