Bundles, versions, and updates - oh my!

[Jameson "Chema" Quinn]

*The story so far:*

The Develop activity uses the bundle format natively. Thus, it relies on
bundlebuilder.py to create bundles and activitybundle.py to install them.
But many activities have developed their own way of creating bundles, and do
not follow the bundle spec (missing or incorrect MANIFEST). This means that
their bundles do not rebuild correctly in Develop, which could lead to data
loss in the current incarnation.

So, I have to fix bundlebuilder to have more error checking, and
activitybundle to throw warnings to encourage people to follow the spec.

Also, there is a major part of the sugar spec unimplemented - the part where
people can install activities by joining a shared instance of them.
Implementing this will, almost inevitably, mean changes in the bundle spec.
If I am going to start enforcing the spec, *it would seem like the logical
time to update the spec to work for updates.*

*Some terminology, and **an idea from the mini-conference:*

By "*a bundle*" I mean a specific set of bytes. Any change in those bytes
means it's a different bundle. Yet actually there are some changes I
generally don't care about. Using a different zip algorithm on the same set
of files, for instance. Another *possible* instance is a change in
translation strings/ localizable icons that does not touch any executable
code. I have a proposal (see below) in which such "extras" would be exempt
from signature. Thus, when precision is important, I will use "*executable
bundle*" to denote everything with the same valid main signature - that is,
everything which has identical executable code.

At the mini-conference, a shortcut to key management was proposed, where a
developer would create a special-purpose key when they started a new
activity, and sign all versions of that activity with their key. This is
called the "*activity's key*" and the signature using this key is the "*main
signature*". This idea assumes that key management is manual - either they
send the key itself to collaborating developers, or they accept and apply
patches and sign the results locally. If we decide that there are important
key management issues missing from this picture, we could do something like
SPKI. Thus the original developer would become an authority, and they would
grant signing rights to other keys. Even in this case, "main signature" will
refer to whatever set of data constitutes a valid signature under this
scheme. Generally speaking, such data should not require network
confirmation, although a finite lifetime is acceptable.

All bundles signed with the same activity's key are known as an "*unbroken
activity thread*". It is assumed that key management would work and that
there would be no forking within an activity thread (aside from, possibly,
temporary experimental branches which never move beyond one machine). I
propose that the unbroken activity thread should be the basic unit of
analysis in sugar, and that each such thread should have a unique "*bundle
ID*" (like org.laptop.392A7F).

If the key is lost or somebody wants to create a new version (and risk
forking), there could be different bundle ID's that are ancestor and
descendant (and handle the same files). These are part of the same "*[broken]
activity thread*", which inevitably means that forks are possible. In my
proposal, broken activity threads can be identified using the alleged
history from the later version, which consists of prior bundle IDs and
last-common-versions.

Also relevant to this discussion is the new planned journal design at
http://wiki.laptop.org/go/Designs/Journal. Note that there are two kinds of
things in the journal: "*actions*", which, as m_stone puts it, are "like UI
completions", and "*objects*", which are more like normal files (pictures,
documents, etc.) with mime types. Actions contain objects, but those objects
are also accessible independently.

See also http://wiki.laptop.org/go/Designs/Activity_Management. "*Favorite*"
bundles are visible in the "*Home screen*" (or "*donut*"), while all
activities are available in the "*activity list [view]*".
*
The issues
*The point of all of this is the user experience that it enables. Some
possible goals (including straw men):

1"no such thing as versions": all actions are associated with a given
executable bundle, and can only be opened with that bundle. The favorites
can be any set of bundles, whether or not these have an ancestry
relationship. The XO does not garbage collect (GC) old bundles until there
are no more instances which use them.

1a"NSTAV ++": there is some way to manually open an action with a different
bundle. What is the UI to make this easier?

2"latest version, but no such thing as forks": All actions are 100%
upward-compatible across unbroken activity threads (when they aren't, you
just break the thread). All actions open with latest version in an unbroken
thread and "favorite" is an attribute of an unbroken thread - the latest
version available is the one that opens. Broken activity threads are treated
as in NSTAV.

2a"NSTAF ++": as above, but broken activity threads are treated as in NSTAV
++

3"no such thing as security": As NSTAF, but auto-updates cross breaks in
activity threads. If you have both sides of a fork, whichever one you got
second shows up as a separate activity.

(->)"xxx with friendly reminders for xxx": when you get a new version of an
activity, there is some UI reminder (badges in the favorite view and on
actions?) to update your favorite and your actions to the new version.
Possibilities: NSTAV wfrf NSTAF, NSTAV wfrf NSTAS, NSTAF wfrf NSTAS.

(cute extra possibility: when you update your favorite activity to a new
version, the UI asks you "why did you do that?". If you give an answer, this
answer is visible in your shared instances of that activity to those with
lower versions. This is safer than advertising new versions with changelogs
from the author, since this way by nature they come from friends/ known
sources. Dubbed "user-generated changelogs" on IRC, which moniker prompted
"<cjb> homunq: OH MY GOD STOP")

"xxx with offloading garbage collection": NSTAV can easily lead to many
actions on the same machine which refer to different bundles from the same
thread. If disk space is short, it is possible to aggressively upload these
to the school server, and download them as needed. This can lead to actions
which do not work until you have connectivity. Note, however, that these
actions would still be *visible* in the journal and that their object
contents (the actual files) would still be accessible from there. Since
we've all lived with just objects, no actions, until now (ca. 1987 MacOS
"Switcher", and other "save workspace" gizmos, aside), I think this is
acceptable.

(*>)"Serious magic": keep usage statistics of all bundles on the school
server, including who manually chooses which bundle version and what their
choices were. If these statistics show a clear and stable preference for
version Y over version X, tell all local XOs to make Y a default over X.

also possible: (*l>)"Serious local magic", where switching from X to Y is
auto-defaulted the Nth time you do it manually on a given machine.) "Serious
magic" is essentially interchangable with "with friendly reminders for" -
thus possibilities such as NSTAF slm NSTAS, or NSTAV sm NSTAF.

*My vote*
I would vote for NSTAF wfrf NSTAS - that is, the most agressive non-strawman
option about auto-updates. This allows for a decent level of garbage
collection. One weakness that I do see with this option is its relatively
strong assumption that later versions are better; I am open to proposals on
how to weaken this assumption, though I do think it is good in 90% of the
cases.

*My proposal
*Before I got pushback on this, I had made some proposals about
implementation which essentially assumed something like NSTAF wfrf NSTAS.
These proposals are available at
http://wiki.laptop.org/go/Talk:Activity_bundles#Proposals_for_update .

*My timeline
*I have enough little bug fixes pending to occupy me for this week. I would
like to have some kind of game plan starting next week. That could be just
"this is too hard to decide now, just start enforcing the activity bundle
format as it stands" but I would prefer to have a clear bundle format, or at
least an agreement on the UI goals it should support, by that time.

Jameson

ps. If you don't like the acronyms, feel free to use the numbers/symbols.
NSTAV slm NSTAS == 1*l>3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080409/ba074a24/attachment.html>