Data Storage and User-facing System Requirements [was Re: [sugar] 9.1 Proposal: Files]
david at lang.hm
david at lang.hm
Thu Oct 30 16:14:53 EDT 2008
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,
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.
More information about the Devel