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.
[edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=4
] The issues (from a user experience point of view)
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.
[edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=5
] Main options
1. *bundle level* (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.
2. *unbroken thread level* (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.
3. *broken thread level* (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.
[edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=6
] Ways of modifying one of the main options:
- There could be some way to manually open an action with a different
bundle. What is the UI to make this easier?
- 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.
- 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.
[edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=7
] Ways of combining two of the main options
- 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).
- 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.
- 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.
[edithttp://wiki.laptop.org/index.php?title=Bundles_and_updatesaction=editsection=8
] Not considered
- Push - type updates
- Blacklists of known trojans (this is only remotely useful if there
is a limited store of keys usable for