Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!rutgers!uwvax!puff!rt5.cs.wisc.edu!blochowi From: blochowi@rt5.cs.wisc.edu (Jason Blochowiak) Newsgroups: comp.sys.apple Subject: Re: BBoard protocols (none) Message-ID: <3148@puff.cs.wisc.edu> Date: 26 Sep 89 06:45:18 GMT References: <8909092230.AA26919@uunet.uu.net> <12526@athertn.Atherton.COM> <902T8M-KAUP@FINTUVM> Sender: news@puff.cs.wisc.edu Reply-To: blochowi@rt5.cs.wisc.edu (Jason Blochowiak) Organization: U of Wisconsin CS Dept Lines: 17 Pardon the sarcasm, but does it come with a kitchen sink? The reason that standards have extensions is because nobody (not even someone with a protocol as grandio-, uh, magnificent as yours) can predict what will work well in the real world. Perhaps defining a prioritized pseudo multi-channel mux/de- mux would work out well, even with some form of optional automatic compression. However, it would seem that design of the higher layers would be more efficient if they were optimized around a _tested_ data transfer layer. This might not be quite so important, but we are talking about micros here, and if you're worried about low bandwidth (1200 bps) communication, you're probably not talking about people with 50Mhz 68040 machines... -- Jason Blochowiak - back at school (again). blochowi@garfield.cs.wisc.edu or jason@madnix.UUCP "What's up pruneface?" - Bugs Bunny in the year 2000