Activity Backward Compatibility
mikus at bga.com
Mon Jul 14 15:30:25 EDT 2008
The way I see it, there are TWO kinds of items for which
"compatibility" needs to be provided -- executables + data :
* Executables : The problem arises from the "quickness" with which
some users (such as I) can switch operating system versions. I
sometimes have two different "streams" on my XO (for example, the
two "builds" in the /versions directory might be from Update.1 vs.
Joyride) -- I can switch in minutes to a different "stream" by just
rebooting. Others (including kids) can switch in tens of minutes to
a different "stream" by installing a new build from an USB stick.
The problem (of providing "compatibility" between Activities and the
operating system on which they run) originated when Activities were
no longer packaged into the "build". Now, unless the "build" to be
fetched is accompanied by a set of Activity EXECUTABLES known to be
compatible with that build, any "leftover from previous times" XO
Activities might *not* receive the particular version of services
from the new-fetched operating system "build" that they expect.
The only solution I see is to provide a set of "compatible" Activity
versions whenever a "build" version is provided. For kids, that
would mean using a facility similar to 'Customization' to put BOTH a
"build" and its "Activities" on the same USB stick. [I used the
word 'similar' because the kid ought to have the options of either
doing a "completely clean" install, or else installing the new
build+Activities __without__ wiping out the existing /home/olpc
content. (The question of providing "backward compatibility"
between leftover /home/olpc data and changed Activity executables is
left to another discussion.)]
* Data : The problem is that Activities compiled in July might not
work correctly with DATA placed into the datastore in February (by
the version of the Activity that was installed at that time).
The only solution I see is to *insist* that each new version of the
Activity __verify__ that it can work with the data (e.g., formats)
that are made available to it. If not, the Activity should notify
the user of the incompatibility.
p.s. One of my "hot buttons" is 'hooking up' additional Activities
which are resident on a removable storage device. Obviously, such
Activities might be at the wrong version level. Therefore I am
interested in there being a "checker" at activity-launch time, which
would compare the current operating-system level against the level
expected by the activity to be launched -- and at least warn the
user if an incompatibility is found.
More information about the Devel