Bundles, versions, and updates - oh my!

[Jameson "Chema" Quinn]

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.

[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=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.
[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=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.

[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=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.

[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=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.

[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=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 signing, which means some kind of
   SPKI, probably including checking with school servers to see if a key is
   from an XO).

[edit<http://wiki.laptop.org/index.php?title=Bundles_and_updates&action=edit&section=9>
] My vote

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.

*Added paragraph*: 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080409/a329df3d/attachment.html>