Librarian: Difference between revisions

From OLPC
Jump to navigation Jump to search
(First draft of Librarian's Requirements and preliminary Design Thoughts.)
 
(+notes)
Line 1: Line 1:
[[User:SJ|SJ Klein]] and [[User:Ashsong|Michael Stone]] had a long chat about the requirements that must be satisfied by a process for getting content onto XOs. We've decided to call a mechanism implementing such process a "librarian".
[[User:SJ|SJ Klein]] and [[User:Ashsong|Michael Stone]] had a long chat about the requirements that must be satisfied by a process for getting content onto XOs. We've decided to call a mechanism implementing such process a "librarian".


== Relationship to existing systems and processes ==
== Requirements ==
These requirements are close to those of traditional Linux package management systems like rpm and dpkg; we should carry them out through an existing system. The way that we intend to manage the ''process'' of packaging content appears to be a bit different, given our [[bundles|bundle]] system -- we will have many packages with incomplete data. We must encourage and provide for packages that are not software but are data (projects and information to be interpreted by other Activities), or are static browsable [[content bundles|bundles]]; these will still have maintainers and dependencies.


The Open Knowledge Foundation has thought a bit about creating a [http://www.ckan.net/ '''CKAN''' repository] for knowledge rather than code.

== Requirements ==


The requirements we identified included being able to:
The requirements we identified included being able to:
Line 16: Line 20:


== Design Thoughts ==
== Design Thoughts ==

These requirements sound awfully close to those of traditional Linux package management systems like rpm and dpkg, though the way that we intend to manage the process of packaging content appears to be fairly different.

Revision as of 22:59, 27 September 2007

SJ Klein and Michael Stone had a long chat about the requirements that must be satisfied by a process for getting content onto XOs. We've decided to call a mechanism implementing such process a "librarian".

Relationship to existing systems and processes

These requirements are close to those of traditional Linux package management systems like rpm and dpkg; we should carry them out through an existing system. The way that we intend to manage the process of packaging content appears to be a bit different, given our bundle system -- we will have many packages with incomplete data. We must encourage and provide for packages that are not software but are data (projects and information to be interpreted by other Activities), or are static browsable bundles; these will still have maintainers and dependencies.

The Open Knowledge Foundation has thought a bit about creating a CKAN repository for knowledge rather than code.

Requirements

The requirements we identified included being able to:

  • install the "most relevant" result or be able to show several probably-relevant results in response to simple-text queries.
  • select language-appropriate content.
  • distinguish between "stable" content, meaning content that no-one can improve any further and "unstable" content which is rapidly changing.
  • remove installed content using standard Sugar mechanisms.
  • update installed content if updates can be found.
  • show related content, as defined by the content packager.
  • prepare an XO for a piece of content, e.g. by examining the XO for required viewers and usefully responding to their absence (i.e. give a warning, give installation instructions, or actually acquire the needed software)


Design Thoughts