Trial1 Software: Difference between revisions
(need to be able to save pdfs or get the interaction with xbook right - the frame doesn't work well right now) |
(inital change from the user's view to the actual operations) |
||
Line 5: | Line 5: | ||
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! |
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 |
=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: |
|||
==Identity== |
|||
* Documents that are created on the laptop are automatically synced to a server using rsync. |
|||
While we eagerly anticipate BitFrost, we need an identity model in place, now! |
|||
* 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 child has a name (which may not be unique). They will also have a ''nickname'', which in conjunction with a ''color'' (can someone provide more detail here), will be unique within the school (region, if a smaller school). This nickname is used for: |
|||
A private key must be generated on the child's machine and the public portion of that key must be put on the server. |
|||
* Instant Messaging |
|||
* URL of laptop file backup |
|||
==Requirements for the School Server== |
|||
Due (only) to the limited time nature of this trial, a child's nickname may remain unchanged. |
|||
Can a child's ''color'' change ? |
|||
The main role for the server is to act as a publishing site for a child's data. |
|||
Each child also has a public/private key pair, stored on the laptop and backed up on the server. The server backup of the identity keys is not done through the normal backup mechanism --- the keys are not available through the web server. These keys are used for: |
|||
* 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. |
|||
* Authenticating the rsync backup mechanism (using 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. |
|||
* ? |
|||
⚫ | |||
The laptops currently shipping have a serial number, but no UUID. The current proposal is to use the laptop ID as a UUID, with a (server software) release note specifying how to change a student's UUID on the server. This UUID is really only important for the restore operation after a laptop software upgrade. |
|||
One possible solution is to assign a UUID at laptop unpack (perhaps even the laptop serial number) which is stored locally on the laptop and not modified by upgrades. A method of changing this UUID would be needed (for replacement laptops). |
|||
===Security=== |
|||
What security? This is a very limited trial, and we are concentrating on user interface issues, not privacy or prevention of identity theft. |
|||
While there is no need to encrypt backups, as they will be publicly viewable on the server, we will use ssh for rsync as it provides backup authentication via private/public keys. |
|||
⚫ | |||
What is a child's view of storage at this point? We don't have a journal yet! |
What is a child's view of storage at this point? We don't have a journal yet! |
||
Line 44: | Line 34: | ||
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). |
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. |
: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. |
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. |
Revision as of 22:54, 1 March 2007
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)
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
The other program that generates content is the camera and slideshow activities. These need no changes at this time.
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)
It sounds like a new version (2.5) just got included in to the build (737), we need to retest and address the remaining issues.
The inability to open web sites from within Abiword (702)should just be accepted and included in release notes.
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.
Taking Photos & Videos
(SJ to fill in his plans here. Many of his concerns (see [Short Term Server Questions]) have been addressed above.)
Watching TV
What's up with PenguinTV ? Bug 666
How is it configured?
P2P is great, but the XOs don't have enough memory to store enough video to share. The result of unleashing 50 BT clients on a school network, all of which are fetching data from machines outside the school won't be pretty.
We will eventually support BitTorrent caching on the school server, but at this point we encourage HTTP instead of BitTorrent to take advantage of the current caching system.
Messaging
User Interface
Who is responsible for this? The buttons are illegible (in English). Is there any interface for directory searching? Any connection outside the local school?
Infrastructure
Who is putting together the Instant Messaging server ? Dan Williams!
How is it managed ?
Making Music
Any issues here ? How do users manage installing new samples, sharing sounds they've created, etc. ?
Games
Are we releasing games in 0.5 ? If so, what games ? Are they all located in the dock ?
Concentration
Tetris
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
We need two types of updates, incremental and complete.
Firmware
What features will the firmware released with 0.5 support ?
At a minimum:
Suspend/resume, as much as we would like to have it in this alpha release, will not be supported. (60, 508)
We still have an issue with NAND programming at Quanta. Mbletsas is unpacking machines in a dead state. Possibly caused by 498, but symptoms are different (xinit cycling, fixed by reflash.)
Peripheral Support
Bug 806 suggests that Tinderbox should have a supported set of an SD card and USB peripherals connected and tested to insure driver inclusion in builds.
Networking
The networking environment for 0.5 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.
Mesh Networking
Can we wait for mesh networking to be fully supported ?
There are two possible blocking problems:
- driver (?) issues preventing reliable operation
- support for multicast
IP Address Assignment
How does the laptop obtain an IP address?(19)
Michalis suggests static IP address assignment for the laptops, using the 10.x.x.x subnet with the last three bytes of the MAC address as the last three bytes of the address.
- Is there any range of addresses available for server (i.e. not used for MAC addresses ?)
This would leave us unable to automatically connect outside of the school.
DHCP is the proposal for alpha release. This will be used for host ip, netmask, domain, and nameserver, but not for gateway discovery (see route selection, below), unless mesh networking does not make it into alpha.
Route Discovery
Route discovery will be done use the RREQ mechanism at the link layer to discover the nearest mesh portal (school server).
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
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?