Talk:Bundles and updates

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

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