Sorry for clogging people's inboxes, but, in the spirit of having a livelier discussion on the mailing list, here are the most-changed sections from the wiki page. If we reach some conclusion here, I will take responsibility for keepint the wiki page up-to-date.<br>
<br><h3><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=4" title="Edit section: The issues (from a user experience point of view)">edit</a>]</span> <span class="mw-headline"> The issues (from a user experience point of view) </span></h3>
<p>The point of all of this is the user experience that it enables.
There are three basic possibilities; sugar can understand just the
bundle level, it can understand the unbroken activity thread level, or
it can understand activity threads including breaks and forks. In the
email I had some names for those based on sugar's perspective of what
exists, I have renamed them below. I believe all of the below options
are technically possible, although of course some are easier than
others.
</p>
<a name="Main_options"></a><h4><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=5" title="Edit section: Main options">edit</a>]</span> <span class="mw-headline"> Main options </span></h4>
<ol><li> <b>bundle level</b> (was called "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.
</li><li> <b>unbroken thread level</b> (was called "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
different activities, as in bundle level.
</li><li> <b>broken thread level</b> (was called "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.
</li></ol>
<a name="Ways_of_modifying_one_of_the_main_options:"></a><h4><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=6" title="Edit section: Ways of modifying one of the main options:">edit</a>]</span> <span class="mw-headline"> Ways of modifying one of the main options: </span></h4>
<ul><li> There could be some way to manually open an action with a different bundle. What is the UI to make this easier?
</li></ul>
<ul><li> 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".
</li></ul>
<ul><li> "offloading garbage collection": The lower options above 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.
</li></ul>
<a name="Ways_of_combining_two_of_the_main_options"></a><h4><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=7" title="Edit section: Ways of combining two of the main options">edit</a>]</span> <span class="mw-headline"> Ways of combining two of the main options </span></h4>
<ul><li> "friendly reminders": Basic behavior is as one of the lower
above options, but when you get a new bundle which, by one of the
higher above options, would count as a different version of the same
activity, there is some UI reminder (icon badges in the favorite view
and on actions?) to update your favorite and your actions to the new
version. Possibilities: bundle level with friendly reminders for
unbroken threads (1 fr 2); bundle level with friendly reminders for
broken threads (1 fr 3); unbroken thread level with friendly reminders
for broken threads (2 fr 3).
</li></ul>
<ul><li> "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. Possibilities: 1 sm 2, 1 sm 3, 2 sm 3.
</li></ul>
<ul><li> "Serious local magic", where switching from X to Y is
auto-defaulted the Nth time you do it manually on a given machine.
Possibilities: 1 slm 2, 1 slm 3, 2 slm 3.
</li></ul>
<a name="Not_considered"></a><h4><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=8" title="Edit section: Not considered">edit</a>]</span> <span class="mw-headline"> Not considered </span></h4>
<ul><li> "Push" - type updates
</li></ul>
<ul><li> Blacklists of known trojans (this is only remotely useful if
there is a limited store of keys usable for signing, which means some
kind of SPKI, probably including checking with school servers to see if
a key is from an XO).
</li></ul>
<a name="My_vote"></a><h3><span class="editsection">[<a href="http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit§ion=9" title="Edit section: My vote">edit</a>]</span> <span class="mw-headline"> My vote </span></h3>
<p>I would vote for "2 fr 3" - that is, pretty agressive 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.
</p><p><b>Added paragraph</b>: I think that straight-out level 2 would
be ignoring the real reasons that people fork (intentionally or
unintentionally). By trying to legislate that "anything that might be a
fork is a separate activity", it would create social pressures for poor
key managment, that would eventually cause some combination of: extra
trojans and extra invisible forks (from compromised activity keys); and
on the other hand, extra breaks in threads (from overzealously
protected activity keys). The scenarios leading to these possibilities
are left as an exercise for the reader.
</p><br>