<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> There are 3 different ideas when we are talking about Journal vs Directories: 1. Whether we are limiting the user to use exactly one filtering category for his/her documents (and lets call them Files and the filter the Files' Directory) or we allow multiple filters (and call them Tags). 2. Whether we are showing the user a open/save dialog which has a Directory tree and File list or we just ask for a name and some tags for save and let the user filter open. 3. Whether the document store is a filesystem or a database. so remembering these points, answers are inlined: Albert Cahalan wrote: <blockquote cite="mid:787b0d920905280307k158c0566q5779fc0a0ad48cd3@mail.gmail.com" type="cite"> <pre wrap="">In graphical environments alone, directories are over 25 years old. Since 8 is less than a third of that, there is only one safe bet. It'd be way more than 25 years, except that we didn't even have graphical environments much beyond that. Directories go back about 40 years. 8 years is just another 20%. </pre> </blockquote> I am sure that 100 years ago when the car was invented, because humanity has been used horses for 5000 years and the next 100 years is only 2% of that, people predicted that we will still ride horses now.... <blockquote cite="mid:787b0d920905280307k158c0566q5779fc0a0ad48cd3@mail.gmail.com" type="cite"> <pre wrap="">This isn't the "Microsoft Windows XP Service Pack 2" feature set. This is a concept that is pretty fundamental in computing. It crosses platforms, it's in our network protocols, and it's even required for all the programming languages that implement Sugar. </pre> </blockquote> Having a filesystem does not conflict with that the user will never ever see one (3. is a differ idea than 2.). <blockquote cite="mid:787b0d920905280307k158c0566q5779fc0a0ad48cd3@mail.gmail.com" type="cite"> <blockquote type="cite"> <pre wrap="">The following things unfortunately cannot be done with a flat filesystem view: 1. Revision based view. 2. Tagging. </pre> </blockquote> <pre wrap=""> First, I think you didn't mean "flat". That's the Journal. Second, both flat and tree systems can handle that. </pre> </blockquote> I meant flat filesystem so I have written exactly that. I meant a filesystem which can be drawn on a 2D surface in a tree (where the files are leafs). Contrast it to a multidimensional "filesystem" where a File can have multiple Directories and which stores all the versions. See I do not want to argue over semantics so if we will have some system which can handle this multidimensional storage then we can call it a filesystem if you insist. After all a filesystem is just a database which maps names to disc block numbers (and the canceled WinFS was marketed as a filesystem after all). What is sure that this future "filesystem" will have a completely different access semantics that for example ext2. <blockquote cite="mid:787b0d920905280307k158c0566q5779fc0a0ad48cd3@mail.gmail.com" type="cite"> <blockquote type="cite"> <pre wrap="">It is a totally different problem that the current Journal barely implements those things but dropping it in favor of "time-tested" solutions is a mistake IMHO. (Note that no filesystem solves those problems I have mentioned.) </pre> </blockquote> <pre wrap=""> No filesystem should! It looks like GNOME 3.0 will get you those features on top of a plain old UNIX-style filesystem tree though, without making the filesystem incompatible with both software and humans. </pre> </blockquote> Have you noticed that as the world evolved, filesystems gained unimaginable capabilities like resource forks, extended attributes, access control lists, transactions? Is your point that we should drop the Journal just to be compatible with those softwares that possibly no child will ever use? I would vote to make the Journal more usable rather than trying to stop the world. </body> </html>