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§ion=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§ion=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§ion=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§ion=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§ion=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§ion=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.
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
