Sometimes ideas start with simple comments. Just like this idea started with this comment in ##gnome on Freenode:
<borschty> it would be nice to see the whole concept of having to save files go away
This started a little discussion, and we were thinking about a way how to get rid of that concept. As Zeitgeist tries to get away from handling with the filesystem anyway, it would be quite fitting to hide the technical details of files as well. The idea we had was to hide the details of saving files from users by simply “having” the files “on their computer” (or maybe in the cloud as well). This would mean that files automatically get saved when they are closed, and users can just continue their work when they access them again. No need to “Save”, no “Do you really want to quit?” boxes. No grandmas asking me “What do I have to do now, I already entered the text but there is this message popping up” (this is how it really happened, sorry if you feel offended when I use “grandma” for “user who got no clue about computers”). This would make handling with documents easier and more intuitive, just like you don’t need to “Apply” your settings when you select them, just close the configuration dialog.
If you think “this is a drastic change!”, then think about it twice. It isn’t very much of that. New users will find it very easy to use their desktop without even having to know what local files are (maybe some files even are in the cloud, they wouldn’t have to make a distinction), while users who know how to save files simply get rid of clicking “Save” every time. Let’s conceive a desktop using this:
User John wants to write a recipe for delicious cake. He opens his word processor and starts writing. Now he has to stop writing and just closes his word processor. He goes away and comes back three days later. In Zeitgeist he sees that he edited a document three days ago which is tagged with baking, recipe and cake. He just clicks on it, finishes writing it and closes his word processor again.
You may have noticed a little problem:
Where did he specify the file name?
The filename could be the “title” of the document. This would make it necessary to give each document a title though (e.g. the headline “How to bake a cake”, which would be used as document title). If the user gives no title, a default title could be used (like in Tomboy) or it could be generated from file meta data like tags and commonly used words, and the current date. This brings me to the next (more amazing) level:
A versioned computer! Let’s assume our user John replaces some ingredients of his cake because they are more delicious. He opens his file again, changes the recipe and closes his application again. Two weeks later his local supermarket burns down and he can’t use the new ingredients anymore (it’s hard to find good examples if you just quickly want to explain your concept 
). As a normal user he would have to change parts of his recipe again. But not our John! He simply selects the recipe he created before he changed the ingredients, and it will be the version he closed at this day! Alternatively, he could select his latest document and just press “Restore previous version” two times. Here is a screenshot of the general idea.
Now let’s further imagine he goes to vacation to Switzerland. The supermarket near his house has the ingredients he needs for the more delicious version of the cake. Unfortunately he only printed his older version and took it with him. Oh no! Fortunately he somehow gains access to a computer running GNOME, logs into his cloud service’s account (Ubuntu One or Click’n Backup for example) which is integrated into GDM as if he was just using a normal user name and got an exact copy of his home desktop. Now he only needs to open the newer version of his recipe and can enjoy delicious cake in Switzerland!
I think you’re getting the idea. Be assured I have no clue how to implement something like this, just the vague idea that openSolaris does something roughly similar with their ZFS restore slider.
Some problems and notes:
What will happen if the computer runs out of power/crashes? – Users will still be able to use File->Save to manually create “revisions” of their file. Apart from that, we could have an autosave feature. If the user closes the program, the autosaves will automatically get inherited in their latest file “revision”. If it crashes the latest working autosave will appear as filename_date_BACKUP.fileextension or something like that (some name that makes the user aware of the file and think “Ah thank god, my file is not lost”).
This will take much space. – Yes, I suppose so as well. But hard drives are getting bigger all the time, and files can be stored online as well.
File names. – I’m not entirely happy with the filename solution. I’m thinking about something like this, where the filename is the heading: Picture
How to call versions of files? – How to call the different versions of files? Revisions? Versions? Snapshots?
Benefits: Users won’t have to make a distinction between local and remote files, they don’t even need to bother about files at all. The process of saving files can easily be integrated into a RCS-like file history. This will make rollbacks easier. I think btrfs might even bring some features to do that.
Migration: How will users integrate their existing data
Final notes: This is a draft of things I’d like to see. Many of the ideas did come from people in the ##gnome channel on Freenode, I am just summarizing my own thoughts on this. Some things are described in detail, while others are barely planned (e.g. the technical implementation). Please tell me what you think, why it will certainly fail, why it will be a great success, your ideas, solutions and whether it is technically possible! I don’t think this will get implemented, but maybe it will deliver some interesting thoughts for the future of the GNU/Linux and PC desktop in general. Now that I read the whole article I also noticed that I’m talking about different ideas and concepts. I hope this won’t make reading any harder 
Anything that means inexperienced users don’t have to pay attention to software since it just does what they expect is a good idea. People used to the way computers have worked up till now and more experienced folks like developers are going to want the old model, where they organise files as they want into a directory hierarchy. Once people get even slightly past casual computer use, they are going to want document grouping; all the documents associated with an animation project, or all the photos associated with a holiday. So perhaps there needs to be a hybrid model. Also, there are namespace issues mapping this stuff onto current filesystem semantics; two images both with the name IMG123.JPG need to be stored into different directories.
Sorry your post has been in the spam queue such a long time.
When I wrote this article I had no clue how to deal with file names either, but now after reading the presentation on wizbit.org I think the file system could just rename the file and the framework that accesses and displays them will work with UUID’s rather than file names.
You dream (and mine) is nearer than you think:
http://www.wizbit.org/drupal/
This already sounds promising. Thanks for the link!
I love your approach to the problem. I might have semi solution for you. Zeitgeist can log renames of files etc too, given we have the right dataprovider. This will allow us to keep track what got renamed. Also with every event (open/close/modfiy) you can store a little payload into zeitgeist. We can put in patches that descibe the diffrence between in an the previous version.
I am just throwing my idea here, and not saying its the best. But the framework offers a solution.
Yeah, I’ve thought of something similar. I hoped Btrfs could do most of the work, but diffs are a valid solution as well (though some files like OpenDocument text are not especially intended to be diffed like people on ##gnome pointed out).
But if it’s possible that might be a good solution. Users would just have their “Video” “Pictures” and “Documents” etc. tabs in their “file manager” and then a timeline, where the dates of accessing the document represent the state of the document as well.
I’m amazed to see Zeitgeist already offers a framework to accomplish this.
Great post, it seems your ideas are closer to what I’d like to see myself than I thought from our conversation yesterday (ie. primarily based on “revisions” instead of auto-save, seeing the file name as something unrelated to the save operation, etc).
I think I’ll also write a post on this topic, or maybe even think about how to implement some of it, but probably not until after I’ve finished exams (in a few weeks).
By the way, a little clarification on Zeitgeist: the project, as it was one year ago, has been divided into two separate code bases (though the developers of both are pretty much the same people): Zeitgeist, being the engine which logs all activities and provides this information over D-Bus, and the GNOME Activity Journal, which is the GTK+ interface showing this information together with other data it’ll take from the Tracker store (for example tags, which we decided not to do ourselves in Zeitgeist anymore). Zeitgeist has also got a website now: http://zeitgeist-project.com/.
@ Seif Lotfy:
I’m sure you knew I’d say this: “OMG!! No!”
Thanks for the clarification on Zeitgeist. I’ll keep an eye on Planet Gnome to catch your post if you write one. As davidnielsen pointed out above there is the wizbit project, which looks like a good approach. Take this video for example, this is very cool:
http://www.wizbit.org/drupal/sites/default/files/wizbit.ogg
Tomboy notes are stored in XML files, and if it works with them, it will work with almost anything. This concept probably is the way to go.
Yeah, I guess I’ll have to take a look at Wizbit.
Ideally I’d like to see revisions at the file-system level, but it would take ages until everyone transitioned to such a file-system so I suppose a higher-level solution is more adequate.
I think a filesystem would be perfectly fine (although maybe just a virtual one). Most users update their distributions with every new release, which would be 6 or in the worst case 8 months. Release dates are being coordinated. I think moving to such a filesystem can be done in short time.
Compability is another topic anyway. Ideally people would just select their files and click on “Share”, which would make them accessible for others via a simple URL (this requires the files to be on an Ubuntu One-like service though). “Legacy users” would be able to browse history via a web interface and download the file they want to have, while users with the supported file system just add the link and can treat the files as if they were local in their file manager.
There is simply no way that I could trust an overlay to give me access to, for example, 110 GB of txt, odt, jpg, png, ogg files. Often I need to access something I haven’t touched in 15 years but need right now.
Metatags are garbage. There are always many songs missing from albums if I try to use anything other than the file system to access music. Images are worse. So I use Gxine and Gthumb.
I can see how Zetigeist would be convenient for someone who hardly ever uses a computer.
But the more that one does, the more files there are, and the less that one can trust anything other than directory, file name, creation date, modification date,
If you rather like working with your computer like this, all power to you, gThumb and Nautilus will still be there at your command.
I personally like managing browsing my music with Banshee or managing my webcam pictures directly in Cheese, so we may have different visions of the perfect desktop.
I was immediately reminded of the Journal/filesystem interface for Sugar (http://wiki.sugarlabs.org) and specifically of some of C. Scott Ananian’s experiments with using it as a normal desktop interface a bit over a year ago. Basically, as an interface designed for kids, the Sugar developers decided to do away with the notion of having to do File > Save > Remember-where-you-put-this, though work isn’t automatically versioned.
The general idea behind the Journal: http://wiki.laptop.org/go/Journal_Activity
Cscott’s attempts to use the idea of unordered paths as tags as a filesystem navigation method for his personal desktop: http://wiki.laptop.org/go/Experiments_with_unordered_paths
Links to code are in the email here: http://www.mail-archive.com/sugar@lists.laptop.org/msg06589.html
I haven’t looked at Sugar very much in the past, but I’ll have a closer look and check the packages out now. The journal sounds like a good idea to me, although it definitely has to be more structured for a “normal” desktop. The latest Gnome Activity Journal(aka Zeitgeist) looks like a pretty good interface.
The experiments with unordered paths are very interesting to read. I’m tempted to switch nautilus to List View and try it myself
All these are very old ideas, which have been implemented many times over, even in some popular (for other reasons) commercial products.
They haven’t become popular at the OS level for a number of reasons, one of which is that OS level functionality should be lower level than that described here, and another is that anything that is not POSIX or WIN32 compatible has a very uncertain chance of surviving.
There is also the reason that virtually persistent integrated storage has some difficult functionality issues to deal with, as the fundamental reality is that computers have small very fast volatile storage and very large very very very slow persistent storage, and how often they should be synchronized is a decision difficult to leave to some automagic.
I think they shouldn’t be implemented on the OS level. I did rather think of an overlay for /home/username/. I’d also be interested which OS has such a thing available.
Even if the ideas may have been implemented elsewhere, they still aren’t available on the Linux desktop.