[IAEP] [Sugar-devel] Journal criticism

[NoiseEHC]

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:
> 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
>> view:
>> 1. Revision based view.
>> 2. Tagging.
>>     
>
> 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 
example ext2.

>> 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.)
>>     
>
> 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.
>   

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090528/b2374700/attachment.htm