Path: utzoo!attcan!uunet!seismo!ukma!tut.cis.ohio-state.edu!rutgers!dptg!ulysses!hector!ekrell From: ekrell@hector.UUCP (Eduardo Krell) Newsgroups: comp.unix.questions Subject: Streams vs what? (was: AIX (is it unix)?) Message-ID: <12226@ulysses.homer.nj.att.com> Date: 28 Sep 89 01:40:03 GMT References: <1702@naucse.UUCP><978@mtxinu.UUCP> <868@cirrusl.UUCP> <12197@ulysses.homer.nj.att.com> <2487@auspex.auspex.com> <12207@ulysses.homer.nj.att.com> <2497@auspex.auspex.com> <12214@ulysses.homer.nj.att.co <2509@auspe Sender: netnews@ulysses.homer.nj.att.com Reply-To: ekrell@hector.UUCP (Eduardo Krell) Organization: AT&T Bell Laboratories Lines: 24 In article <2509@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >I shall simply note that the streams mechanism is having stuff added to >it in S5R4 to support out-of-band data and to support TCP urgent data, >and note therefore that if the current BSD socket mechanism needs change >to support the ISO protocols, perhaps even including new system calls >(although, frankly, I would rather take e.g. Keith Sklower's word for >it that it's necessary than yours, since he's one of the people actually >*implementing* the ISO protocols on BSD), this cannot necessarily be >claimed as an advantage for S5 streams, since they required modification >as well.... But while the changes to Streams to support out-of-band and urgent data were minimal, changing BSD sockets to support OSI or some other layered protocol would involve much more work. And again, without a framework like Streams, it would have to be done all over again for the next great Protocol to be. Conceptually, Streams is a clear winner. The implementation might not be perfect, but then I never argued that. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com