Path: utzoo!attcan!uunet!cs.utexas.edu!longway!std-unix From: jason@cnd.hp.com (Jason Zions) Newsgroups: comp.std.unix Subject: Re: Standards Update, Recent Standards Activities Message-ID: <770@longway.TIC.COM> Date: 2 Jul 90 15:27:15 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: Hewlett Packard, Information Networks Group Lines: 37 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jason Zions Regarding the Snitch Editor's fine report, in the section discussing 1003.12 comes the following sentence: > Our snitch, Andy Nicholson, challenged readers to find a reason not to > make DNI endpoints POSIX file descriptors, but has seen no takers. How about because it constrains implementations to make DNI kernel-resident? How about because the semantics of operations permitted on POSIX file descriptors are a poor match for many transport providers? Read()/write() are stream operations; only TCP is a stream transport provider. OSI TP0/2/4 maps much more closely to stdio and fgets()/fputs() in that it is record-oriented. What does it mean to seek() on a network endpoint? A significant branch of the UNIX(tm)-system and POSIX research community believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks are among the leaders here. I feel only slightly squeemish about accusing them of having only a hammer in their toolbelt; of *course* everything looks like a nail! I think it would probably be acceptable to have a DNI function which accepted a DNI endpoint as argument and attempted to return a real file descriptor. This function would check to see that the underlying transport provider could present reasonable semantics through a POSIX file descriptor, and would also check that the implementation supported access to that transport provider through a kernel interface. Jason Zions * UNIX is a trademark of AT&T in the US and other countries. ** Obstreperous iconoclast is a behavioral trademark of Jason Zions in the US and other countries. Volume-Number: Volume 20, Number 85