[Sugar-devel] Activity as regular objects proposal

[Aleksey Lim]

On Tue, Jul 28, 2009 at 09:00:49AM +0000, Aleksey Lim wrote:
> 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

Anyway [1] proposal doesn't do any non-obvious or complicated stuff,
just the other way:

* it simplifies activity registry related code(less code, less bugs)
  since all job does OB[3] and shell just need to track DS
* from users POV, it adds only one(but obvious) thing - if user deletes
  Journal entry which named "Terminal-25" he loses version 25 of
  Terminal activity, and if he has "Terminal-24" Journal entry, next
  time when after click on that entry(or entry in Home view)
  Terminal-24 will start

[3] http://wiki.sugarlabs.org/go/Features/Object_Bundles

-- 
Aleksey