There are 3 different ideas when we are talking about Journal vs
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:
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%.
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....
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.
Having a filesystem does not conflict with that the user will never ever
see one (3. is a differ idea than 2.).
The following things unfortunately cannot be done with a flat filesystem
1. Revision based view.
First, I think you didn't mean "flat". That's the Journal.
Second, both flat and tree systems can handle that.
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
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
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
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
Sugar-devel mailing list