From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Thu,  3 Feb 2011 12:45:33 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.37-rc6-18+; KDE/4.5.5; x86_64; ; )
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201102031245.33842.dexen.devries@gmail.com>
Subject: [9fans] files vs. directories
Topicbox-Message-UUID: aa519a94-ead6-11e9-9d60-3106f5b1d025

As this list seems to be open to discussion of strange OS-related ideas, he=
re=20
goes my question:

why do we keep distinction between files and directories? Does it provide a=
ny=20
extra value over model with unified file/directory?

A possible consideration for representation of unified files/directories is=
 a=20
three-part file: name (& other meta), byte-stream (=3D=3Dcontent), ordered =
list of=20
subfiles (=3D=3D subfiles/subdirectories). In a way, that'd be somewhat sim=
ilar to=20
files with two forks you can see on some OSes. Or, to put it the other way=
=20
around, it's like a directory with extra section for one unnamed byte strea=
m.

Path sematnics stays exactly the same:
read(open("/foo/bar")) returns byte stream related to entry `bar' in (for l=
ack=20
of any better word) object  `/foo'.

read(open("/foo")) returns byte stream under entry `foo' in the root object.

readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchi=
cal=20
section of object `/foo'.

The sourece of the idea is a (www) CMS I'm working on which doesn't make su=
ch=20
distinction, and it somehow makes some sense -- at least as served over HTT=
P &=20
addressed via URIs.


=2D-=20
dexen deVries

[[[=E2=86=93][=E2=86=92]]]

> how does a C compiler get to be that big? what is all that code doing?

iterators, string objects, and a full set of C macros that ensure
boundary conditions and improve interfaces.

ron minnich, in response to Charles Forsyth

http://9fans.net/archive/2011/02/90