Library use cases

When children look for materials and collections they can use, we want to provide them with a simple interface offering links to as much information as is available.

Dynamic views of collections

We want a dynamically generated library to present content already on the xo, with

• navigation that updates when collections are installed or removed.
• a way to search through the system of available collections (potentially a different way of searching for each collection, defined by that collection's maintainers)
• a way for bundles to interact with users.

A simple type of interaction is response to following links. This can be built into a static set of pages or files, but this gets large quickly with branching options. This can also be done by taking in data from the collection material and from the user, applying a function to it, and displaying the result -- still without writing new information to disk. Finally, the most complex interactions store state as the user adds or modifies preferences and information.

Designing browser-based activities

Aside from a simple notion of a liabrary as a collection of elements to be viewed or interacted with, there are more granular activities whose primary purpose is to make, modify, view and share materials. These local services need to be able to present dynamic views; some of them are well suited to libraries that offer interface and database widgets.

Services aside from the Library that will want read and sometimes write access to a specific changing collection of data, as well as access to a browser for rendering and interface: • An xo-wiki (its own activity or an xol using the webserver) • Browse clones (Gmail with an offline component, Browse + java-webstart + an applet) • A javascript spreadsheet that can save and read data (via dan b.)

Of course there are many more. (local google maps : take a USB GPS device and browse through map tiles with their interface; many javascript-heavy apps that already know how to render properly on the XO through the browser)

Notes

Implementation notes:

This can done by embedding the browser in another activity; feels messy.

Any daemons involved that start when such an activity launches should end after it closes. A script that updates static materials and then launches the browser, or a webserver that starts and lets a browser access it, would need to shut down cleanly when the browser is exited.

Perhaps we could insert rainbow or something like it between a webserver process and its children. Something like a fancy verison of exec that also passes on some change data (asking for certain options to be turned off for children). mstone has been thinking along similar lines; and is interested in seeing what can be done.

Questions

(mstone and mako)

q: do these speak scgi?

a: yes.

q: if you do the latter, they presumably share a pipe; is that their only communication channel?

a: yes.

what if you can get the webserver to launch / run new code in a restricted environ; is it necc to make the entire webserver be unprivileged? is there a way to make its children run within rainbow?

the webserver only needs access to activity bundles... so the whole thing can run within a restricted environment.

q: Two interesting parts : (not launching of subprocesses in restriction.)

1) how should a service like a webserver be run? as an activity with hacks?

2) the datastore will eventually have access checks. arbitrary access to the datastore could be tricky.

( promotes Taste the Rainbow )

how does this interact with the current journal notion of what [meta]data any activity can access?

for one, the journal doesn't provide deep searching.