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...)