Librarian: Difference between revisions

From OLPC
Jump to navigation Jump to search
(note)
No edit summary
Line 1: Line 1:
''from a discussion b/t [[User:SJ]] and [[User:Ashsong|Michael Stone]] about the requirements to be satisfied by a process for getting materials onto XOs.''
''from a discussion b/t [[User:SJ]] and [[User:Ashsong|Michael Stone]] about the requirements to be satisfied by a process for getting materials onto XOs.''


== Problem Statement ==
== Relationship to existing systems and processes ==
We currently have a story about installing an item which goes like this:
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.

"Jane visits http://xyz.org/bundle.xo[l] and her bundle is installed."

While adequate for the present, this story fails to explain how Jane found her bundle and it fails to explain what happens next week when someone unrelated posts a new version of the bundle, when Jane wants to suggest a revision, when Jane wants to remove the bundle, etc.

Consequently, we believe that a better story is needed.



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


== Requirements ==
== Requirements ==


Some of the things that Jane wants to do from the beginning to the end of her experience with a bundle include:
Requirements should include being able to:


* '''install''' the "most relevant" result or be able to show several probably-relevant results in response to simple-text queries.
* '''install''' the "most relevant" bundle or be able to show several probably-relevant bundles in response to simple-text queries.
* '''select''' language-appropriate content.
* '''select''' a language-appropriate variant of a bundle.
* '''distinguish''' between "stable" content, meaning content that no-one can improve any further and "unstable" content which is rapidly changing.
* '''distinguish''' between a "stable" bundle, meaning a bundle that no-one can improve any further and an "unstable" bundle whose contents and packaging are in flux.
* '''remove''' installed content using standard Sugar mechanisms.
* '''remove''' an installed bundle.
* '''look''' for the existence of other variants or versions of a bundle.
* '''update''' installed content if updates can be found.
* '''show''' related content, as defined by the content packager.
* '''show''' related things, perhaps bundles, 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)
* '''check''' how compatible an XO is with a bundle, 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)
* '''give feedback''' on an installed bundle





== Design Thoughts ==
== 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 [[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.

Revision as of 23:29, 27 September 2007

from a discussion b/t User:SJ and Michael Stone about the requirements to be satisfied by a process for getting materials onto XOs.

Problem Statement

We currently have a story about installing an item which goes like this:

"Jane visits http://xyz.org/bundle.xo[l] and her bundle is installed."

While adequate for the present, this story fails to explain how Jane found her bundle and it fails to explain what happens next week when someone unrelated posts a new version of the bundle, when Jane wants to suggest a revision, when Jane wants to remove the bundle, etc.

Consequently, we believe that a better story is needed.


Requirements

Some of the things that Jane wants to do from the beginning to the end of her experience with a bundle include:

  • install the "most relevant" bundle or be able to show several probably-relevant bundles in response to simple-text queries.
  • select a language-appropriate variant of a bundle.
  • distinguish between a "stable" bundle, meaning a bundle that no-one can improve any further and an "unstable" bundle whose contents and packaging are in flux.
  • remove an installed bundle.
  • look for the existence of other variants or versions of a bundle.
  • show related things, perhaps bundles, as defined by the content packager.
  • check how compatible an XO is with a bundle, 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)
  • give feedback on an installed bundle


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.