[Sugar-devel] Activity as regular objects proposal

[Aleksey Lim]

On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote:
> 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.

+1, the way which was chosen by soas is a good example(all activities
come from .xo bundles)

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

Well, for me "0.82 doesn't work with 0.84" is very strong requirement 
btw it relates to [2]

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

Yeah it raise many new questions.

In my mind we can do the first step on this road by creating
activity-less Composite Journal entries[2](objects w/o activity DS
field), so over activities(like Develop) can change activity's code
inplace. And delegate(for the first time at least) all maintenance
procedures (like what version I can change, what version is my backup
copy) to users, they can do this if all activities will be Journal
entries.

[1] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose
[2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file
 
> Daniel
> 

-- 
Aleksey