Talk:Bundles and updates


Jump to: navigation, search

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

Actually, this is just the proposed short-term solution:

When installing a new bundle, check the hash (for bundles using old format, calculate a hash of all bundle contents, in order of inclusion in the zip). Iff there is not an identical bundle (by hash) installed, install, without uninstalling it.

Only uninstall bundles when manually deleting them from the journal.

Open journal entries with: same hash as creator, then same service ID/version as creator, then same service ID as creator, then first app which handles their mime-type.

    • proposed solution with next generation datastore/journal

Actually, nothing here requires next-gen datastore, just more work than the minimum.

first, get "open with" dialog to group by thread into submenus.

uninstall, and reinstall as needed. (Max of 2 versions of an activity)

Use signatures for auto-update - add control panel for "trusted signatures"

  • 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

as currently: a .xo is, internally speaking, a zip file with a certain structure

    • proposed solution with next generation datastore/journal

unpack bundles on download - a .xo is either a bunch of files and metadata about structure, or a tarball (for better differential versioning). Implicitly turned into a .tgz whenever exported to another file system.

  • issue: signing
    • proposed solution using current datastore/journal
each activity thread has a key.
kept in separate journal object
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
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:
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...]
warn before sharing.
  • issue: encryption
    • proposed solution using current datastore/journal
    • proposed solution with next generation datastore/journal
Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
OLPC wiki