Activity Backward Compatibility

[Steve Holton]

On Mon, Jul 14, 2008 at 3:30 PM, Mikus Grinbergs <mikus at bga.com> wrote:
> 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.)]

Let's be practical. On the wiki, we regularly use a single page to
document a component or activity without reference to which version of
the component we are documenting, despite enormous differences in the
versions. If we're lucky, we can keep people from overwriting
documentation of *released* activities with the details of how it
works, this week, in Joyride.


> * 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).

...complicated by the fact that Activities are intended to be
colaborative across XO's which might be running different activity
versions on different build releases and possibly different
hardware...

Trying to build a completely conformist world is madness in any
venture. with XOs it just seems antithetical to the whole project.

This dictates the need for diverse application versions to be able to
interoperate....
...which dictates the need to freeze the interfaces between
components, document them fully, test them extensively, change them
only when absolutely critical (or better yet; never at all), etc.

The need to tightly control the *interfaces* between components
dictates the need to make the components themselves as small and
concise as possible.


> 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.

Quis custodiet ipsos custodes?

-- 
Steve Holton
sph0lt0n at gmail.com