[Sugar-devel] Activity as regular objects proposal

[Aleksey Lim]

On Tue, Jul 28, 2009 at 12:24:52PM +0545, Daniel Drake wrote:
> 2009/7/28 Aleksey Lim <alsroot at member.fsf.org>:
> > The problems that 0.84 has in case of activity versions are:
> >
> > * it can't upgrade activities if they were pre-installed from
> >  native packages; it makes process of upgrading activities
> >  from .xo impossible
> 
> In reality Sugar's message is confusing here and I don't think any
> distributor will mix-and-match the two ways of installing activities.
> (either they'll use distro packages and disable .xo, or they will
> exclusively use .xo e.g. OLPC).

Well, thats question not only about distributor's comfort but about
users possibility to install new activity version.
Otherwise what your suggestion is?
* for pre-installed activities, using only non-xo methods to update
* using only non-xo activities
* using only xo activities

> This is a larger problem and I don't think yours is a solution, since
> it will result in wasted disk space

Proposal is not about storing all versions but about possibility of
storing not only one(last?) version and we can uninstall old versions
by removing entries from journal.

> and we still end up with the
> confusion of how activities can be installed and which one is being
> used.

There is no confusion, sugar is aware of what versions of particular
activity it has by using datastore.find() method, so user can run
`rpm update`, install any version by downloading .xo and sugar will run
last version(when user create new activity instance) or run particular
version(if activity object requires it). 

btw, activity can declare, in activity instance object, what activity
version(range) should be used with this particular instance object.

> > * sugar can have only one activity version installed at the same
> >  time i.e. it could be useful to have several versions
> >  simultaneously e.g. to start proper version when join request
> >  arrived(activity version of arrived request could be different
> >  to installed version)
> 
> I think this calls for wider discussion. Having multiple versions of
> the same activity installed sounds silly. Instead, activity designers
> should be encouraged to strongly avoid making backwards-incompatible
> protocol changes, just like the principles of any other software
> designer. Once everything is compatible, this problem goes away.

Well we can't say to activity developers that they must write
backwards-incompatible activities otherwise we won't host them on ASLO.
In that case using compatibility ranges of versions could fix problem
(w/o obliging developers write complicated code for
merge/support-backwards-incompatibility).

> Sugar
> should continue to make no promises about interoperability between
> different major releases (e.g. no promises about 0.82 talking to 0.84)
> and hence if it is necessary, activity developers are allowed to break
> compatibility once every 6 months, which should be more than enough.

I like this idea only if all sugar users have 100% access to internet.
And they can run "upgrade my 0.82 to 0.84 from internet" process by one
click. But imho thats impossible in case of educational infrastructure
around of the world.

> Finally, I personally don't like the idea of having activities (as in
> applications) in the journal. The journal is for recording what the
> user has done.

imho activities are the same kind of objects - user should have chance
to edit/hack/share them like other sugar objects.

-- 
Aleksey