Since the beginning of computer time, all computer systems have been based on the idea of a "computer file". OSX, Linux, Windows, and every other OS has been based on the system of files and folders and filenames and crap like that. I'm not too versed in computer history. Has anyone ever tried making a computer system that does not use files?<p>In my opinion, referring to the data that computers deal with as "files" made sense in 1954 when every large company had a "paper file system", but in 2014, I think its time to come up with a new system that better mirrors how we use computers.<p>I'm working on a project I'm calling "Library Transfer Protocol", which is aiming to replace the concept of "file" and replacing it with 'Library item'. Basically, in 2014 computer usage more closely mirrors the workflow of an author (revisions, publishing, etc), rather than an employee filling up a file cabinet for internal use (thank to the facebook and the like)<p>Before I get too into this project, I'd like to know if anyone has ever tried doing something like this before.
Several experimental systems have proposed replacing the traditional file system with what they call a "single level store": you have data structures in memory, then the OS saves them and restores them as needed from disk storage - but there are no traditional files on the disk, and the users don't interact with the disk storage at all - they just interact with the data while it is in memory. In this scheme, the disk storage is something like the pagefile in a conventional OS, but that's all there is - there are no conventional files.<p>An interesting single-level store was discussed by Robert Strandh in his 2004 proposal for a Lisp operating system, Gracle. I can't find the original paper on the web anymore but some pertinent excerpts are in <a href="https://github.com/jon-jacky/Piety/blob/master/doc/gracle_excerpts.txt" rel="nofollow">https://github.com/jon-jacky/Piety/blob/master/doc/gracle_ex...</a>. Strandh referenced another experimental OS with a single-level store called EROS. I see he has a more recent LispOS at <a href="https://github.com/robert-strandh/LispOS" rel="nofollow">https://github.com/robert-strandh/LispOS</a>.
BeOS had a nice idea, although it still used files. It's file system doubled as a database, and you could add arbitrary columns to files. For example, contacts were empty files in a special directory, and had attributes like "address", "name" and so on. Mails were also stored in plain files, but unlike mbox/Maildir all the metadata was stored as attributes, not in the files, making it easy to process them with scripts, or to sort them in the file browser.<p>Its a lot like the never-finished WinFS from Microsoft.<p>Funnily, modern file systems (extfs3/4, NFTS, HPFS+?) all support extended attributes in some form or another. However, they are currently only rarely used: Mostly for the "this file was downloaded from the internet, do you really want to open it" flag. I wish more programs would use them to store interesting metadata, but it's basically a chicken and egg thing now.<p>Windows and GNOME also have concepts where you can have calculatable attributes - you have a little library that looks up metadata in a database or parses it from the file, and then serves it as an additional attribute on the file (visible in the file properties tab). You can see it e.g. on mp3s or word documents in windows. However, it doesn't seem to be widely used either, and I wouldn't be surprised if that function has been gutted out of GNOME lately.
>Basically, in 2014 computer usage more closely mirrors the workflow of an author (revisions, publishing, etc), rather than an employee filling up a file cabinet for internal use (thank to the facebook and the like)<p>How did you come to this conclusion about patterns of usage? I'd think the typical user/consumer would more likely have 1000 mp3 files rather than 1000 personally authored Microsoft Word documents (or Photoshop PSD files, etc.)<p>What about another common usage such as digital camera photos? The digital camera (or iPhone) has jpg "files". How would the user mentally translate the "files" living on a FAT32 flash card and copy them to your "Library Items" storage system? Do they keep 2 mental models of storage paradigms in their head? If your proposal includes a driver/wrapper for hiding the FAT32 file inside the concept of "library item", it seems like you're just renaming "files" to "library items". It's more a shift in terminology rather than shift in paradigm as a sibling comment already noted.<p>The filesystems in an operating system (NTFS, ext3, etc) are already implemented as <i>special purpose databases</i>. The "rows" are file id entries and they each point to the "blobs" which are the file contents. Whatever you propose to build has to reimplement this underlying "database" as well. Whether you call the rows of that database "files" or "library items" or "objects" or "documents", it isn't going to revolutionize the approach.
Apple's Newton OS used object-oriented data stores called "soups" rather than a file-oriented storage paradigm:<p><a href="http://en.wikipedia.org/wiki/Newton_%28platform%29#Operating_system_and_programming_environment" rel="nofollow">http://en.wikipedia.org/wiki/Newton_%28platform%29#Operating...</a>
MTS, z/OS (its a long story), OS/360 and basically everything written before Multinixs (the pre-cursor to Unix). Didn't use files. Stone age computers.<p>The hierarchical file system as you listed it really only started to come into its own in the mid 60's. With LISP machines at MIT and Multinix at AT&T.<p>Storing data in <i>files</i> as you call it is old, and well known solution to this problem. Because finding a node on a tree is simple, and this is how file systems tend to work. Because thinking of objects, as subsets of various super classes of objects is easy for people to understand, when you don't explain it in those words.<p>The reason very old OS's didn't store things like this, is because there weren't much permanent storage. Actually MTS uses what are roughly <i>files</i> but uses a dot notation to seperation files. Which will look similar to usenet<p><pre><code> misc.data.logs.9-12-2014.dat
</code></pre>
Where data is your current record.<p>:.:.:<p>I support moving to a more revision, publish, etc. structure. But moving away from the tried and true hierarchical model will be difficult. Even an object based file system will develop a hierarchy of inheritance.
There's a long history of mocking and decrying the file as a user-level concept, and many applications hide the concept from the user, even though they store user data in the filesystem. Music players (such as iTunes) are an example: there are songs, albums, and artists, but files do not show up in the UI in any way. This is standard practice at the application layer. However, implementing something at the OS layer with the expectation of exposing it directly to the user goes against the current thinking that it's the application layer's job to provide user-friendly concepts, and that the job of the OS is merely to support the application layer in doing that.<p>If providing support for application-level user-friendly abstractions is what you want to do, then I would suggest studying applications with UI abstractions that you admire and judging your OS storage layer by how well it supports application development.
Files are a shorthand for "documents". Don't be so hung up on terminology.<p>First, look into history more--there are several non-hierarchical (read: flat) file systems out there.<p>Second, while the workflow might mirror authoring more closely (which I think is horsehit, but that's neither here nor there) the <i>artifacts</i> of that process are what matter. Existing notions of a "file" map very cleanly onto the storage and organization of such artifacts.<p>There is an argument to be made for having better querying capabilities or permissions or whatever, but what is to be gained from throwing a commonly-accepted idiom away?
On the AS/400 there was no traditional file system, the only storage was in a database.<p><a href="http://en.wikipedia.org/wiki/IBM_System_i" rel="nofollow">http://en.wikipedia.org/wiki/IBM_System_i</a><p>Unlike the "everything is a file" feature of Unix and its derivatives, on OS/400 everything is an object (with built-in persistence and garbage collection).
WinFS was supposed to be in Windows 7, unfortunately they decided to drop it, I was really looking forward to that.<p><a href="http://en.wikipedia.org/wiki/WinFS" rel="nofollow">http://en.wikipedia.org/wiki/WinFS</a>
Browsers. Browsers are de facto operating systems (though typically running on another OS, not on bare metal), and they don't think in files. They handle windows, tabs, documents, document elements (DOM nodes) etc.
The One Laptop Per Child laptop uses a Journal instead of folders -- <a href="http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal" rel="nofollow">http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal</a> -- and GNOME's "Activity Journal" project is similar. (Smartphones are starting to use some of the same ideas, too.)
I've toyed with the idea of replacing files with processes. If you have some data that you want to keep, you have a process that holds it in its process memory, and can give it other process via an IPC mechanism (if the other process is local) or over the network (if remote, although you could of course also use the network locally).<p>I never got around to trying it out. I think I may have tried to start some discussion on usenet along these lines maybe 10-15 years ago, but no one seemed interested.<p>A "directory" would simply by a process that provides some kind of lookup service to let other processes find the data storage processes that contain the data they are looking for.<p>You'd still have disks on your computer, but they would be mostly used as swap space.<p>The system would include some standard simple data holding and directory processes that implement a Unix-like namespace and permission system, but it would be easy to override this for data that needs special treatment. Just write a new data holding program that implements the special treatment you want and knows how to register with the standard directory processes.
For your project make sure you plan what to do if one application created the item, but another program wants to open it.<p>Don't try to do it by applications registering types they can open - this never succeeds, there are simply too many file types in the world.<p>Also think about how to send data to someone else.<p>And finally think about how to integrate with existing devices that still use files.
<i>> I'm working on a project I'm calling "Library Transfer Protocol", which is aiming to replace the concept of "file" and replacing it with 'Library item'. Basically, in 2014 computer usage more closely mirrors the workflow of an author (revisions, publishing, etc), rather than an employee filling up a file cabinet for internal use (thank to the facebook and the like)</i><p>Please define how a "library item" is different from a "file".<p>Is it made of bytes that can be read into a buffer and accessed?<p>(If not, how can an H.264 video or MP3 object exist as a library item and be processed?)<p>Do you not have spaces which assign names to library items?<p>The Hyper-Text Transfer Protocol has already replaced the concept of "file" with "resource". A URI doesn't necessarily name a file.
Your proposal doesn't really sound like it deprecates files, but rather that it enhances them with attributes. Most operating systems other than Unix have already expanded on the file as a bag of bytes to one that supports features such as extended attributes and forks. Even most contemporary Unix file systems have xattrs (most notably XFS), but overall they seem to have had limited impact, and in the case of NTFS-style alternate data streams, even introduced some nasty security risks.<p>Really, what you seem to want is a file system with built-in version control and network sharing? Git and Mercurial are already virtual file systems of sorts, I guess.
Look up Common Lisp's file handling functions. The number of options to open a file seems ridiculous in our world, but in that one function you can see a history of how many different ways "files" used to be accessed.
Did you just describe git? Git has revisions of files, and they can be tagged, merged, etc. It still works on top of a conventional file system though, because why reinvent the wheel?
While not exactly an answer to your question, you might find it worthwhile to take a look at the 1060 NetKernel platform - <a href="http://1060.org" rel="nofollow">http://1060.org</a><p>"NetKernel can be considered a unification of the Web and Unix implemented as a software operating system running on a microkernel within a single computer."<p><a href="https://en.wikipedia.org/wiki/NetKernel" rel="nofollow">https://en.wikipedia.org/wiki/NetKernel</a>
What your building sounds like a document management system: <a href="http://en.wikipedia.org/wiki/Document_management_system" rel="nofollow">http://en.wikipedia.org/wiki/Document_management_system</a>. Might be worth looking at some to see how they'd fit with what you're envisioning. Even if you write it yourself, it can be helpful to see how others have solved the same problems.
Yep, check out camlistore (<a href="http://camlistore.org/" rel="nofollow">http://camlistore.org/</a>). It can be quickly described as a big database at which you throw all your content, along with a JSON containing any attributes you want. These attributes are indexed and then searchable.
I think the file metaphor is a must for the separation of OS and applications. Unless you have a better conceptual framework to deal with this problem, you'd probably live with "files".