As this list seems to be open to discussion of strange OS-related ideas, here
goes my question:
why do we keep distinction between files and directories? Does it provide any
extra value over model with unified file/directory?
A possible consideration for representation of unified files/directories is a
three-part file: name (& other meta), byte-stream (==content), ordered list of
subfiles (== subfiles/subdirectories). In a way, that'd be somewhat similar to
files with two forks you can see on some OSes. Or, to put it the other way
around, it's like a directory with extra section for one unnamed byte stream.
Path sematnics stays exactly the same:
read(open("/foo/bar")) returns byte stream related to entry `bar' in (for lack
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 hierarchical
section of object `/foo'.
The sourece of the idea is a (www) CMS I'm working on which doesn't make such
distinction, and it somehow makes some sense -- at least as served over HTTP &
addressed via URIs.
--
dexen deVries
[[[↓][→]]]
> 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
