On Thu, Feb 3, 2011 at 10:58 AM, Bakul Shah <bakul+pl...@bitblocks.com> wrote:
> On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries <dexen.devr...@gmail.com>
> wrote:
>>
>> why do we keep distinction between files and directories?
>
> David Cheriton's `thoth' operating system didn't keep this
> distinction. But every other OS I know of keeps them
> separate. IIRC thoth provided functions for getting the
> first child or next sibing given a path name. [Cheriton used
> words like father, son, brother -- this was pre-PC!]
>
>> Does it provide any extra value over model with unified file/directory?
>
> They serve functions. A directory is an associative table,
> indexed by a string key. A file is an array, indexed by an
> integer. But most filesystems do store some attributes with a
> file thus breaking this simple model.
>
> One advantage of always storing a directory with a file is
> that you can represent file attributes via a directory. Then
> you can have an extensible attributes model. XML probably
> maps well to this model.
>
> Not sure doing so in plan9 makes any sense but you could
> build an experimental OS around it! But if you go this path,
> do consider providing a few more datatypes in the filesystem
> (integers, file-id, strings, ...). Basically persistent data
> types. Or just use an object or relational database as your
> filesystem.
>
I'd tend to agree with this sentiment. I think, particularly in the
construction of synthetic file hierarchies as interfaces, the tendency
to do what is expected (from a disk file system perspective) often
gets in the way of the sensible interface. The world has become
considerably richer than collections of byte-stream files, yet we have
no way of notionally representing richer structures in the name space.
I've actually got some words on this in a position paper I've been
crafting, I'll try to get it out posted to my blog before too long.
-eric
