[Sugar-devel] Activity as regular objects proposal

[Daniel Drake]

2009/7/28 Aleksey Lim <alsroot at member.fsf.org>:
> 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.

The journal can't delete activities that are installed by a package at
/usr/share/activities, and I also think it is unlikely that our users
would realise to do this even if it were possible.

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

I was referring to confusion by deployments and those who are
diagnosing bugs and soforth.

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

Sounds like overcomplication.


In response to your question on how I think it should be done, I feel
that it's time to admit that packaging activities in this way is a
mess. We should leave packaging and the related complications to the
experts - packagers, and the package manager, and then we can stop
wasting our time on it. For some kind of cross-distro package manager
compatibility, someone recently raised the idea of PackageKit which
seems well worth investigating and given its rapid development can
probably be adapted to our needs.

IOW I feel that the concept of sugar providing prepackaged binary
activities should die. I think you would be a good person to work on
this, and it is an interesting problem.

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

It's nice to have the freedom to post whatever I want on ASLO and I'm
not saying that should change. I'm free to write a buggy activity or
one that isn't sugarized and post it on ASLO. Even though my activity
is low quality and doesn't fit into the desktop, I'm welcome to post
it. The consequence is that my activity probably won't be included in
deployments, and I'll get some mails from testers making suggestions
how I could improve it, and maybe even some patches. I'd say that this
case is no different.

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

The responsibility of keeping all machines in sync can be handled by
the deployments, with the aid of good tools from Sugar/distro/OLPC.
This is how it already works in the field. It's not your problem, but
you could certainly help improve those tools and their concepts which
seem a bit neglected right now.

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

Good point, but this seems to be beyond what sugar is capable of at
the moment and raises more questions. Perhaps once there is the
ability to modify your activity within sugar, the development activity
could offer functionality to package up the modified version and save
it in the journal. Exactly how the user could modify activities, how
the user-modified activity would be saved on-disk alongside the
original one, how they would be differentiated in the UI and how the
user could switch between the two seems to be out of scope of this
discussion -- or at least I can't see how it would be covered by your
proposal.

Daniel