Talk:Bundles and updates: Difference between revisions

From OLPC
Jump to navigation Jump to search
(issues and proposals)
Line 29: Line 29:
== issues and proposals ==
== issues and proposals ==


* issue: activity auto-update
* issue: '''activity auto-update'''


** proposed solution using current datastore/journal
** proposed solution using current datastore/journal
Line 35: Line 35:
** proposed solution with next generation datastore/journal
** proposed solution with next generation datastore/journal


* issue: file formats / compatibility
* issue: '''file formats / compatibility'''


** proposed solution using current datastore/journal
** proposed solution using current datastore/journal
Line 41: Line 41:
** proposed solution with next generation datastore/journal
** proposed solution with next generation datastore/journal


* issue: bundles
* issue: '''bundles'''


** proposed solution using current datastore/journal
** proposed solution using current datastore/journal
Line 47: Line 47:
** proposed solution with next generation datastore/journal
** proposed solution with next generation datastore/journal


* issue: signing
* issue: '''signing'''


** proposed solution using current datastore/journal
** proposed solution using current datastore/journal
Line 66: Line 66:
::::pro: standard, solid
::::pro: standard, solid
::::con: uses keyrings but we don't want to, bigger (~1M)
::::con: uses keyrings but we don't want to, bigger (~1M)
:::option 2: openPGP.py
:::option 2: [http://pypi.python.org/pypi/OpenPGP/0.2.3 openPGP.py]
::::pro: python native API, under .5M, more flexible
::::pro: python native API, under .5M, more flexible
::::con: python native backend (probably fixable), has had much less code review, alpha (0.2.3), more flexible (to shoot self in foot)
::::con: python native backend (probably fixable), has had much less code review, alpha (0.2.3), more flexible (to shoot self in foot)
Line 79: Line 79:
:::warn before sharing.
:::warn before sharing.


* issue: encryption
* issue: '''encryption'''


** proposed solution using current datastore/journal
** proposed solution using current datastore/journal

Revision as of 22:39, 3 May 2008

Please discuss. :)

Rethink this

After a good conversation on IRC today, I want to jot down my thoughts. This will be (for now) less organized and complete than the rest of this page, but represents my latest thinking.

Before talking about activity bundles, it is useful to talk about general datastore objects. This is true because an activity bundle is one, but more importantly, because these are the main objects of the verb that is the bundle.

An activity has five kinds of data to save, as defined by scope (that is, what other applications may have a good reason to see that data):

  • simple files - a picture, a text document. These have the broadest scope - you may reasonably want to open any of these with a number of different activities over their lifetime, either standalone or in the context of a project.
  • project files - a web page, with pictures and css and the rest; a "roll of film" or slideshow; an audacity file; a movie editing project. These are files which give some sort of structure to a set of subfiles. Generally, any given person will have one preferred editor and/or one preferred viewer for each project type at a given time, but that preference may change over time.
    • related but not identical: the simple list of subfiles. This must naturally be in a standardized format that the datastore can understand and parse, or there must be some way to obtain such a list in a standardized format (for example, ls)
  • activity-specific - the scope for this is essentially one activity and maybe its descendants or cross-platform variants, since it is probably not worth reimplementing support for this in another activity. In general, it will be safer/more sensible to scrub this data before sharing a file/bundle, but it would not be the end of the world if it were shared.
    • generalized - things that make sense for any instance of the activity. These should be kept to an absolute minimum to avoid configuration-itis - I just checked Firefox's 7 tabs of configuration and found nothing that is in principle 100% necessary, given some decent instance isolation - but some will be unavoidable. Say, identity, in an email activity.
    • instance-specific : current view info, undo stack (insofar as this is not encoded in file history). Stuff that it probably will never make sense to open with another activity. There is little penalty for losing this.
  • metadata - tags, creation time, shared-with. Cross-activity, usually user-editable, understood by journal.
  • private signing keys. This should be kept associated with the file they are used to sign

(more later...)

issues and proposals

  • issue: activity auto-update
    • proposed solution using current datastore/journal
    • proposed solution with next generation datastore/journal
  • issue: file formats / compatibility
    • proposed solution using current datastore/journal
    • proposed solution with next generation datastore/journal
  • issue: bundles
    • proposed solution using current datastore/journal
    • proposed solution with next generation datastore/journal
  • issue: signing
    • proposed solution using current datastore/journal
each activity thread has a key.
kept in separate journal object
unencrypted
used to generate service ID
use activity key to sign XO public key
use XO private key to sign HASHES
signature format RFC4880
separate file
signed metadata: signing activity hash, signing activity (signed) service ID
list of valid signing hashes and service IDs (one hit is enough - no need to use both) in activity.info
signatures generated by sugar.
QUESTION: how do we generate this format?
option 1: GPG
pro: standard, solid
con: uses keyrings but we don't want to, bigger (~1M)
option 2: openPGP.py
pro: python native API, under .5M, more flexible
con: python native backend (probably fixable), has had much less code review, alpha (0.2.3), more flexible (to shoot self in foot)
    • proposed solution with next generation datastore/journal
same except:
activity key
kept as "master file" of action bundle which contains [key, activity bundle]
activity bundle is itself a bundle: [MANIFEST, ...files...]
private
warn before sharing.
  • issue: encryption
    • proposed solution using current datastore/journal
    • proposed solution with next generation datastore/journal