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