Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sockets vs streams. An attempt to answer the original question Message-ID: Date: 12 Sep 90 17:38:47 GMT References: <1990Aug28.162400.17811@zoo.toronto.edu> <38584@ucbvax.BERKELEY.EDU> <1990Sep4.172923.25008@spectrum.CMC.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 54 Nntp-Posting-Host: odin In-reply-to: lars@spectrum.CMC.COM's message of 4 Sep 90 17:29:23 GMT On 4 Sep 90 17:29:23 GMT, lars@spectrum.CMC.COM (Lars Poulsen) said: lars> In article <1990Aug28.162400.17811@zoo.toronto.edu> lars> henry@zoo.toronto.edu (Henry Spencer) writes: spencer> The way to do i/o on Dennis's streams was with "read" and spencer> "write". Network i/o, in general, looked *exactly* like local spencer> device i/o. If you want to keep UNIX like semantics. Unfortunately you really want to do typed data, if only to include passing file descriptors, and OOB signaling, and these do not fit well with traditional UNIX style interfaces. 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). lars> In article lars> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> And for good reason! read() and write() on file descriptors is not pcg> the most amusing interface. It is much more convenient to have ... pcg> [features] Hey, I take exception to the [features] summary -- I was describing not a set of extra features, but a completely different philosophy based on communication with active entities represented by IPC ports. An alternative to the UNIX style file descriptors to access passive files. It can be as simple and terse as the current UNIX style. lars> The problem is larger than that. As commercial programmers have lars> often said, unix read() and write() is not a very good interface lars> for files, either. It is a good interface for SIMPLE TEXT files, lars> and very little else. Uhm. Here we differ. The UNIX style of accessing file is excellent for any type of file, because any type of file can be mapped onto untyped byte arrays (a.k.a. virtual memory segments), by the use of suitable library procedures. Unfortunately non storage like entities are not easily mapped onto untyped byte arrays. lars> Having a guaranteed subset of compatible functionality has allowed lars> very productive use of the "building block" philosophy. Having a way to lars> specify a remote conenctions "as if" it were a filename would allow more lars> things to be prototyped with simple shell scripts and pipelines. The problem is that modeling everything as a passive entitity is far less flexible than modling everything as an active entity. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk