[Sugar-devel] Activity updater

[Ties Stuij]

This might be a nice time to convey some observations about the
activity updater:

- Lets first set the premise straight here: we foremost cater
organisations that have to centrally manage large batches of XO's in
some way. Their preferences have priority over individual XO owners
that know what they're doing. Or in what context DO the majority of
you see sugar mostly used. I'd really like to know.

- related: of course students should also be allowed to have the
freedom to mess with activities, but if activities are used in the
classroom, all of them should often all have the same version of a
particular activity, in the same way as they are expected to all have
the same version of some textbook, so as to not be incompatible with
the teaching scheme.


Having that gotten straightened out, the following points come to mind:

- In general I'd like to see the pages referred to by the groups file
to be the canonical version-list that the individual activities adhere
to. Let me expand on this below:

- atm the updater checks both the pages supplied by the urls in the
relevant groups file and the update url entry in the activity.info
file of the installed bundle. Whichever of them is higher, wins the
contract, so to say. The problem here is that the version linked by
the activity.info file might: a) not work with the current build. b)
be buggy. A sugar environment deployment doesn't have any influence
over this activity, short of editing the info file in the activities
they ship. So my suggestion would be to check for the info url for the
activities found on the pages linked from the groups file. Other
activities are presumably installed by the kids themselves, and could
safely be updated, if the kids so choose.

- There's no way to downgrade activities through the updater. Imagine
one accidentally puts a version of an activity on the XO that's
broken. The current updater will only install versions that are newer,
not older. So there's no way to control that. I'd rather see the XO's
adhere to what the groups file dictates, if the activities are
included.

- I'd like to see some sort of delete function. This is more a
feature-request of course, and it would need some more infrastructure
as far as I can see, because the activity might have been installed by
the student, and can have nothing to do with the curriculum. Also the
student might still want to keep it for some reason. And the reason
for the feature have got nothing to do with a sadistic urge to control
the lives of the studens, but are of a more practical nature. An
example: some of our in-house activities are huge. We've got two
different content activities, both of which span 100+ MBs. Eventually
they are likely to be merged in an on-demand version that compasses
both technologies. We all know about the memory-constraints of the XO
and so we have to get rid of them. So some sort of blacklist
functionality would be nice.

That's about it.

/Ties