> >Data, Data, Where fore art thou Data. > (Sounds like a bad 'ST:TNG' quote.) > >I have been planning to write an article for the list on my idea, so here >goes. > >In the original concept the designers had for the BeFS, they foresaw a >relational database. This would allow the user to manipulate all their data >as entries in a database. This is a twist of the concepts from the already >existing file systems. > >A file system is only a means of mapping an identifier (usually a absolute >file name) to data (the files contents) and its attributes (such as >permission, ownership, creation time etc). [snip] Mathew, you've got alot of interesting ideas on this subject. I've thought about many of these things as well over the last few years. For those who are interested, here are a couple of links to articles with similar themes: The Death of File Systems http://www.useit.com/papers/filedeath.html A Dream of an Ultimate OS http://okmij.org/ftp/DreamOS.html Both these papers, like your posting, make many profound observations that bear thinking about. Unfortunately, I don't see how we could apply these ideas to OpenBeOS. If we did, it wouldn't be an OS that anyone (developers or users) would recognize as the BeOS. You make the comment "A file system is only a means of mapping an identifier..." Yes, and this identifier is generally tied up with the semantics of the file system. For example, I probably have any number of files called "readme". But that simple name alone is not sufficient to identify the object. So I have to specify '/volume/subdir/foo/ readme' and '/volume/subdir/fee/fum/readme', etc. Now I don't claim that hierarchical trees represent the best way to access information, but at the system level, you have to have some kind of organization, and the standard Unix-like file systems have been around a long time and are well understood. If we want to replace it with something else, then what? There must be ten thousand alternative ways to represent information -- which is the best, which is the one everyone could agree to? That's the problem I see with your suggestion, Mathew. If we took it seriously and actually tried to implement it, the project would probably be set back by at least two or three years. The notion of how data is stored using the file system is so engrained all thruout the OS from the lowest levels of the kernel all the way up to applications, that you couldn't pull it out without disrupting practically everything. Even if you could do it, it wouldn't be the BeOS, it would be something else (maybe better, maybe not). You and I and probably most of the people on this list could probably find 1000 things that we don't like about the current BeOS architecture including the file system. But as long as we agree to implement it, we all know where we stand and the goals are clear. Take that away, and you have months, even years of discussion, debate, and bickering as everyone tries to hash out their own ideas of the new world order. I just can't see what your proposing as being anything that could be implemented in even R2, R3, R4, etc. let alone R1. What you're proposing is a leading edge, revolutionary OS model. It's probably a good academic project and someday many, if not all, of those ideas will probably make it into real world operating systems. But I don't want to spend years in the OS laboratory trying to find out what new semantics work. I see the OpenBeOS project as a very practical, pragmatic undertaking. The BeOS's design principles, if not leading edge, are at least solid, practical, well understood and well defined. That's the main reason that I think OpenBeOS actually has a chance of succeeding.