Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!hub.ucsb.edu!spectrum.CMC.COM!lars From: lars@spectrum.CMC.COM (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sockets vs streams. An attempt to answer the original question Message-ID: <1990Sep4.172923.25008@spectrum.CMC.COM> Date: 4 Sep 90 17:29:23 GMT References: <1990Aug28.162400.17811@zoo.toronto.edu> <38584@ucbvax.BERKELEY.EDU> Organization: Rockwell CMC Lines: 31 In article <1990Aug28.162400.17811@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >spencer> The way to do i/o on Dennis's streams was with "read" and "write". >spencer> Network i/o, in general, looked *exactly* like local device i/o. > >spencer> This is the way it should be, unlike what both Berkeley and >spencer> AT&T have done (both have reluctantly conceded that most people >spencer> want to use "read" and "write" and have made that work, but >spencer> their hearts were clearly elsewhere). In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >And for good reason! read() and write() on file descriptors is not the >most amusing interface. It is much more convenient to have ... [features] The problem is larger than that. As commercial programmers have often said, unix read() and write() is not a very good interface for files, either. It is a good interface for SIMPLE TEXT files, and very little else. Having a guaranteed subset of compatible functionality has allowed very productive use of the "building block" philosophy. Having a way to specify a remote conenctions "as if" it were a filename would allow more things to be prototyped with simple shell scripts and pipelines. On the other hand, great flexibility leads to a loss of device independence, witness VMS' proliferation of pseudo-device drivers as an example of where the path of customized interfaces may take us. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM