Trial1 Software

  This page is monitored by the OLPC team.

What activities are available to kids in early OLPC trials?

This page specifies the activities (and the underlying software) available to participants in the early country trials being performed with B2 XO hardware and XSX school servers.

While we are gaining a better understanding of the software needed for the 3Q07 release of the XO laptop, we need to agree on the features we are providing to these early users. Their response is crucial to our success!

The Publishing Cycle

In the initial trials we want kids to be able to read documents, create new documents, share documents with others and be able to explore the larger world. For our initial trials we're proposing using a very simple method for doing this:

• Documents that are created on the laptop are automatically synced to a server using rsync.
• Any documents a kid creates are available through a web interface on the school server.
• Documents can be saved/viewed through the web browser.

As a child's flash starts to fill up an automatic process will prune the files that a child has saved. However, the push to the server is only additive - files deleted off a child's machine are not deleted from the server.

A private key must be generated on the child's machine and the public portion of that key must be put on the server.

Requirements for the School Server

The main role for the server is to act as a publishing site for a child's data.

• Each child will have an account on the server and their laptop will be automatically set up to push data to the server via rsync and ssh.
• There will be a program on the server that reads the config data out of sugar's interface configuration and generates per-child color and nickname information. Name collisions will be handled on the server.

Laptop Storage

What is a child's view of storage at this point? We don't have a journal yet!

The current proposal is to go with a file and directory model, as Abiword and Gecko already support that model. Each child has a home directory. This is where all applications place documents created by the child, and begin browsing for files to open.

This home directory should be a subdirectory of /home/olpc, as /home/olpc contains user configuration files such as public/private keys.

A child's home directory is rsync'ed to a school server periodically. This rsync will only ensure that newly created files are transferred, it will not properly mirror file renaming or moving (the source file will remain on the server as well).

One suggestion on the table is to provide a file manager for deletion, renaming, and copying. This provides little functionality, if run on the laptop, as neither deletion or renaming will function properly (unless the rsync period is a day, which prevents networked interaction in the classroom), and copying can be provided by the writing app itself.

Documents in this directory on the XO will be deleted after a couple of weeks (sooner, if XO disk space runs low.) Once a document is deleted from the local machine, we need a mechanism for students to download/restore them from the server, for re-editing or inclusion in another document. Such functionality should be provided by the browser application.

First pass is no deletion.

How can a student delete files ? (Bug 831) Should they be allowed to ? There is no interface for doing so (and given our storage model, unless the file is deleted immediately, it must be deleted on the server.

What are the chances that documents can be named in the native language? (Bug 814)

Reading

The web browser will be the starting point for reading. It will provide access to both the content already downloaded onto the laptop and that available through the school library.

We need to be able to read the following formats for initial user testing:

• Web content (through the web browser)
• Flash content (either gnash or through the adobe flash reader - talk about redistribution agreements)
• Video content
  • Stream large videos (need to talk to Thomas to see if they have anything here)
  • Saving small videos (need a way to save as from the browser)
• Audio Content
  • OGG and MP3 (need to investigate a redistributable mp3 decoder - fluendo?)
• PDF Content (xbook, but needs to be hooked up better - also need an "open" dialog)
• .doc format (abiword)
• .odf files (abiword?)
• image files (what the browser supports)
  • Need to support the ability to save an image from the browser so it can be used in abiword

How are bookmarks (into a ebook, and on the www) managed ?

Are the scroll and rotate keys (816)on the front bezel supported ?

Known Issues:

• Language support splotchy, including Urdu (884)
• DPI related (Bug 889)
• configuration directory needs stable name (Bug 847)
• new browser windows (Bug 515) and popups (899, 878, 542) confuse gecko
• memory (29, 860)
• gmail gives warnings about scripts executing because the machine is so slow. Need to increase that timeout.

Do we provide our simple instructions for installing flash to the kids? 864 What about gnash? (652)

Writing

Writing is largely supported by abiword. Right now abiword supports simple text. Things that really need to be added to abiword include:

• Support for Open, Save and Save As
• Support for including images in a document from the filesystem
• Adding support for tables?

The other program that generates content is the camera and slideshow activities. These need no changes at this time.

Interoperability with Reading

Documents written by the children will be stored in .doc format. To facilitate reading these documents, it is important that the web browser be capable of opening documents of that type using Abiword when clicked on.

Note that the directory into which the document is downloaded before opening in Abiword should not be the student's home directory, but rather a directory that isn't automatically backed up to the school server.

The interaction when saving PDFs from the web needs some work. Right now it's saved into the frame, when it should either be saved or immediately read with xbook. Need a decision on that.

Known Issues

• Correct country typefaces being loaded? (Bug 417)
• File browser opens onto / (Bug 404, which needs reopening)
• Crashes when opening a document (824, 762)
• Pointer too small (822), flashes (823)
• Various other miscellanious bugs (826, 771, 764, 763, 761)

Hopefully a new libabiword will soon enter the build (970), so please retest (and address) the remaining issues when that is done. I think this will fix Bug 417 and Bug 814 at least.

The inability to open web sites from within Abiword (702)should just be accepted and included in release notes.

Included Activities

Activity	Included	Notes
Web	Required	Lots of changes required to support document reading/writing. Also plugins for media.
XBook	Required	Needs a change so you can open a pdf off the filesystem. Also might need an icon so you can launch it and open a file from the filesystem. Right now it's hidden.
Write	Required	Needs changes as listed above.
TamTam	In	Nice program, but doesn't last long vs. OOM.
Camera	Required	Needs to be able to save small videos and needs some more work
Slideshow	Required	Haven't seen it, but I guess we need this? Talk to Walter.
Memory Game	Not Required, Might Be Out	Has issues, might be removed.
Calc	Maybe	Apparently .ar folks have a calculator. Haven't seen it. But might be nice to have.
BlockParty	In	It works, it's nice and fun.
Chat	Not Required	Very busted right now. If we have some runway between now and tests it's a nice to have but not required. If we do have it it's XMPP only and not very feature rich.
PenguinTV	Not Required	Needs better feeds, needs a sane way to add feeds from the web? It's also very slow and very big. OOM is a regular feeder on this program.
RGBPaint / MTPaint	Required	It's in the devel tree, apparently works pretty well.
Etoys	In	It's fine as is.

Sugar Fixes

Note these have not been discussed with Eben or Marco - they are a starting point only.

• Edge resistance isn't working. Should have been moved to activation at the corners quite some time ago.
• When the initial home page comes up, the frame vanishes and no one knows what to do.
• When you launch an activity, the frame should go away once the activity comes up.
• Multiple launching of activities is a huge problem. Not sure if we can fix that by Trial1.

Overall Infrastructure

Software Update

The mechanism for performing software updates over the network is under development. Probably not part of Alpha.

How are these updates triggered ? Authenticated ?

What information should not be touched on upgrade (even from USB key)?

• User documents in /home/olpc
• UUID (if present) and serial number
• Binding to a school server

There will only be one kind of software update supported. This update will completely overwrites the contents of the laptop's flash.

Firmware

What features will the firmware released with Trial1 support ?

At a minimum:

• Safe battery charging, Bugs 543, 596, and 685)

Suspend/resume, as much as we would like to have it in this alpha release, will not be supported. (60, 508)

Networking

The networking environment for Trial1 is drastically different from what we hope to ship later. It will be completely IPv4, and will rely on NATs to simplify both deployment and the required routing software.

The network design guidelines set forth in Trak ticket 19 should be followed.

Mesh Networking

Mesh networking will be supported in Trial1 !

One school server will be deployed per school, and will serve as a mesh portal for two or three mesh segments (on channels 1, 6, or 11). If additional coverage is needed, a laptop may be deployed as a reliable mesh node.

IP Address Assignment

DHCP will be used to assign a network address to the laptop. Specifically, host ip, netmask, domain, and nameserver will be required.

Route Discovery

Route discovery will use the RREQ mechanism at the link layer to discover the nearest mesh portal (school server). If this is not integrated and tested for Trial1, route discovery will instead ue DHCP.

Optimal routing back to a laptop on the mesh will be enabled by the NAT mechanism (which masquerades all packets passing through a mesh portal as coming from that server.)

Service Discovery

What service discovery is needed ?

• DNS (discovered through DHCP)

Each laptop is bound to a school server which will provide it with backup and library publishing services. How is this binding established and maintained?

DNS presents an obvious solution. Each laptop will initialized with an unqualified name for the server it is bound to. DNS then provides the discovery mechanism which allows for remapping the laptops onto existing school servers.

What granularity of naming should be used ? Class level (say 15 to 20 laptops for each name)? Or individual, which each laptop assigned a unique server name?

Right now, I'm leaning toward both a unique server name and unique laptop name per child entered into DNS.