Yeah. What Daniel said. Seriously, Matthew (Matt?) - I have a bad taste in my mouth about hierarchical (SP?) file systems, too. Why does (say) my mom have to know that her scanned image is in /boot/home/scannedImages/family? Accessing as a database, esp with attributes makes all kinds of sense. And, really, if you look at most of the files in a file system, most people have no real interest in accessing them. All of the apps, device drivers, etc are not documents. Some sort of differentiation between documents and apps in such a way that I can browse my documents by project, date of modification, etc easily would be ideal. Esp if it hid filesystems, disks, etc. But, as Daniel said, that is beyond the scope of OBOS. NOW - what I propose is this. Why don't you build something that works like what you are looking for? Make it run under R5. Certainly, if you have the source, it *WILL* work under OBOS. It doesn't have to be PART OF OBOS to be cool or interesting. Then, when it is done, show it off. We can evaluate it at that point. T The neat thing about the BeOS architecture is that it is so modular. I can build a screensaver without jumping through a lot of hoops. It even runs at the same time as Be's. When I am 100% happy with it, I can dump Be's and just run mine. Likewise, anyone can write a new server. R6, for example, was to contain a Crypto Kit. In the next newsletter, I design and build a whole kit (a small one). It took me less than 3 hours to build the client, server and C++ api for it. I have often thought that many of the cool things that people want to build could be done, but it is hard to grasp, after submitting to the tyranny of the MS Hegemony, that the OS is easy to add to. BeOS makes it easy to build new servers, clients and kits. Then, if we (the community) decided to incorporate the code, it would already exist, work and would require just a little back fit. >>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.