Data Storage and User-facing System Requirements [was Re: [sugar] 9.1 Proposal: Files]

[david at lang.hm]

On Thu, 30 Oct 2008, Benjamin M. Schwartz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Erik Garrison wrote:
>> It seems from my reading of mailing lists, IRC logs, and listening to
>> conversations with people that we are trying to resolve all of these
>> issues by implementing more code to get around difficulties imposed by
>> our current data storage implementation and security model.
>>
>> My argument is that we can do less work and get an improved result from
>> the user's perspective by removing the layers of code (datastore and
>> security restrictions) which prevent applications from behaving as they
>> normally do on other systems.
>
> Erik:  If you want applications to behave as they do on other systems,
> then why not just use an other system?

if Sugar is only the Journal then I would definantly say to not ship Sugar 
until it's ready, and even then I would question it's value.

however Sugar is a lot more than just the Journal.

The problem is the attitude that some people seem to have that becouse 
Sugar is new and innovative, all existing software should be re-written to 
use all the new Sugar goodies.

this means that until Sugar is complete and re-implements all the worlds 
software, there will be a significant number of people who cannot use it 
becouse it can't run something that they need

for a system that's running Linux on a x86 cpu, the fact that it can't use 
the vast majority of the software available today (including the 
opensource software) is embarrasing. but beyond that, it limits how 
effective the OLPC can be by limiting the users (and as a side effect, 
limiting developers)

it's time for everyone to give up the dream that Sugar will be the biggest 
OS in the world and everyone will adapt to it. (some people have 
acknowledged this publicly, most have accepted it privatly, but some 
people still seem to think that they can force the rest of the world to 
adapt to Sugar)



Switching from 'the Journal is the main API, and we will implement some 
other mechansims to simulate a filesystem' to 'provide a POSIX filesystem 
and make the Journal be a view to that filesystem' would change the 
Journal from a liability to an asset.

it would eliminate one of the biggest barriers for existing software (the 
window manager stuff would just about cover the remainder), and with the 
Journal being optional it can be used where it makes sense, and bypassed 
where it doesn't make sense (or where it's not ready yet)

note that the POSIX filesystem does NOT mean that the user needs to 
directly access the filesystem on the nand, it could be that the file 
access is done through FUSE so that additional metadata can be stored 
along with the file. they key is that it needs to be transparent to the 
software so that existing software doesn't need to change.

David Lang