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