Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Unified I/O namespace: what's the point?
Message-ID: <13220@cs.utexas.edu>
Date: 4 Oct 90 22:34:05 GMT
Sender: jsq@cs.utexas.edu
Organization: IR
Lines: 29
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)

We all know that the best standards codify existing practice, while the
worst standards attempt to introduce new features without knowing what
they'll do. For example, POSIX 1003.1 has slaughtered some of my best
code and thrown huge roadblocks into my porting attempts, simply by
adding an unnecessary feature (sessions) that hadn't been proven to work
in the real world. It's a nice standard---except where it enters totally
uncharted territory.

Now we're looking at another possible addition to UNIX that hasn't been
widely tested: a unified namespace for opening all I/O objects. But we
already have a unified file descriptor abstraction for reading, writing,
and manipulating those objects, as well as passing them between separate
processes. Why do we need more?

I propose that we stop discussing this issue in comp.std.unix and start
implementing real-world solutions. My approach is to separate opening
and connecting into special programs, and stick to file descriptors for
almost all applications. If you have a different solution, such as
overloading open(), why don't you start playing with your library and
seeing what works? 

When we have a lot more real-world experience with various solutions,
we can come back here and consider standardization. Until then, ciao.

---Dan

Volume-Number: Volume 21, Number 187