Activity Backward Compatibility

[Mikus Grinbergs]

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.


mikus


--------

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.