[olpc-software] Use cases and design scenarios for software handling

[Alan Cox]

On Wed, Mar 15, 2006 at 04:19:22PM +0000, Mike Hearn wrote:
> + The teacher goes offline because he wants to try the program out in 
>   the privacy of his home. 
>     * The software must work correctly offline. 

(if it makes sense to do so...)

>   students, or the students need to be able to easily find it on the
>   network and pull it themselves.

And it may be an adhoc network. Mobile phone bluetooth may be a better
example of that in practice today - people conciously send things to each
other because they are cool/useful.

>     * Minimal storage should be used on the laptop.
>       This means the system must be smart enough to only transfer
>       translation files for the languages the students need.

I'd remove "translation files for the languages" and just say "files". Suppose
I want to use a "learn to read maps" program. The localisation here will be the
local maps and you won't want to pull map/tutorial data for other towns just
your own.

>           + Some students aren't interested in geography at all. They
>             don't want to run the program, and would rather the storage
>             be available for something else.

Some phones/pdas deal with this by actually asking the user when they want
to install/add something and there is no room. "To use foobar you will need
to make room, select a tool you no longer need or hit cancel"

>     * We cannot and should not expect any knowledge of dependencies 
>       or package management technologies. Sharing should either Just
>       Work or fail because the laptop is not new enough. Failing due
>       to conflicting packages, namespace conflicts, or other UNIX 
>       esoterica is not acceptable.

They won't I suspect go away. Since succeeding isnt possible, failing must be
possible but it has to be in a user understandable fashion, and it probably
can be because it is about using the right language or automating things.
And yes it should not happen if at all possible to avoid.

>     * Kids should be able to share upgrades as well. Ideally again
>       by swapping minimal changesets.

And installs. Again watch phone/pda people and you get some interesting clues. 
Java phone applets all have an update, its fundamentally built into the way
they are installed. Users also bookmark apps they dont need at the moment but
might want back. Finally (and this is really important in the project case)
they shout across the office "has anyone got Frob 500". We can do that , we
can even multicast or SD for Frob 500 and let users cross install programs.

>         * It must be easy for kids to see where their storage is going, 
>           and to free up space by removing things they no longer care 
>           about.

or the device needs to ask them to make decisions when it is close to out
of space. Could even offer a list of programs sorted by least recently/least
regularly used algorithms.

>       way to access a program from the user interface, it must not be
>       taking up any storage on the system. It is unacceptable for the
>       operating system to "degrade" over time in the way Windows tends
>       to.

Agree - except if the user chooses to keep bits. And then the kept bits must 
be easy to zap too. Scenario..

	Student A spends all night playing an educational game (say nethack)
and gets to a really deep level, then goes to bed. In the morning school 
requires a new program but there is no room. Student A will want to keep the
other bits but not the program so that they can reinstall nethack later.

>     * Ideally, it must be extremely trivial to distribute software built
>       using the SDK. Best case scenario, there's no work to do at all.

Agreed - the Sun J2ME devkit and the Nokia phone devkit do this for the 
phone java packages and it just works.

>       mesh. Similar concepts could provide local Wikipedia copies and
>       other geek-utopia ideals :)

Yeah, if you can figure out how not to get arrested for distributing wikipedia
in many of the countries.

>      * How do we bring these people onto the OLPC Linux platform?

Make it brainessly easy. Make it profitable ? Some practical suggestions

	- Simulator for generic PC systems for developers
	- Re-use the simulator so the same apps can be used elsewhere in the
	  world in schools with generic PCs
	- Equivalent to the J2ME devel kit 'make package' functionality

>              Is there any support in the software distribution system
>              for handling policies like "only 5 licenses may be in use
>              simultaneously"? Or is that a headache only western
>              educational groups have to deal with?

How about letting them figure that out themselves 8)


One area not covered and large is system upgrade - do we want to be able to
just replace/reinstall/reset the underlying OS without touching the packages
on top and the user config (at least as first resort) ?

Another is privacy - passwords/authentication models/encryption.