Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)

Eben Eliason eben.eliason at gmail.com
Mon Jul 14 10:24:30 EDT 2008


2008/7/14 Kim Quirk <kim at laptop.org>:
> I've been thinking about this problem for the last year -- when it first
> became obvious (to me) that:
>
> 1 - we were definitely NOT going to be able to lock down APIs for at least a
> year or two
> 2 - we have no control over the activity developers and the maintainability
> of any given activity (unless we decide to 'own' it)
> 3 - all standard 'best practices' for ensure that 'customers' can keep
> working seamlessly through upgrades have to be dropped for the OLPC project

Agreed on all of the above.

> And the only 'real' solutions I have come up with are:
>
> 1 - completely separate the activities from the OS in order to help people
> understand that most activities are NOT supported or maintained by OLPC;
> they need to be able to upgrade activities as needed and not wait for new
> releases from OLPC

This is one of those steps that makes sense politically, but doesn't
really pan out so well in practice.  We really *do* need to have
maintainability of a subset of activities.  It's unfortunately that
defining the set we want to 'own' gets people so flustered, but I
still think we may find we need to make some form of commitment in
this regard.

> 2 - push for 'school year' releases (fall and spring); where a school will
> pick a release and use it for the entire school year so we don't have to
> worry about upgrades in between that time

Yup.

> and, most recently you will hear me pushing for:
>
> 3 - Encourage schools to completely reflash (cleaninstall) their laptops
> each year. At the end of the school year, you save away kids data (hopefully
> that is done automatically) and you do a cleaninstall of the next year's
> image; retest all the latest versions of Activities that you want to use;
> and provide 'clean' laptops to the kids at the start of the next school
> year.

I think this would be a real shame, honestly. It completely tosses out
the benefits of the Journal as a structure for ones interactions and
created objects.  It means I can't incorporate photos that I took over
the summer, or last year, into a story I wrote (for instance, even a
"what I did this summer" essay that we've all written at least once).
It means I can't go back and look at some math homework I did to
refresh myself on how a particular algorithm works.  It means I can't
create a new etoys project from an experiment I made last year but
didn't have time to continue.  It means that I lose references to all
the friends/groups I've made.  It means that my computer is reset to
factory state and I have to change my personal preferences all over
again.

I think we need to find a way to make solid, secure updates without
wiping the machines clean each year; otherwise we're contradicting our
goals for learning, as I see it.

- Eben



More information about the Devel mailing list