[Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library

[Aleksey Lim]

On Sat, Feb 27, 2010 at 04:05:02PM +0000, Gary C Martin wrote:
> On 27 Feb 2010, at 07:17, Aleksey Lim wrote:
> 
> > Hi all,
> > 
> > Before this moment some binary actitieis on ASLO bundle per architeture
> > blobs since binaries didn't weight much. But it doesn't play in case of
> > http://www.geogebra.org/ which is Java based application (bundling blobs
> > per architecture will mean 50M of dependencies and 5M of geogebra itself).
> > 
> > Since Sugar Platform can't grow endlessly, some dependencies can't be
> > included to SP(here Java). But bundling some of them will be pretty
> > overkill(Java, Qt etc). At the same time fetching dependencies on
> > demand(on first launch) could not fit to some deployment models.
> > 
> > So, the question is - how handle such non SP big dependencies in ASLO.
> > Possible answers:
> > 
> > 1) hmm.. what are you talking about, sugar is pure python environment
> >   and blobs(not python) is evil, ASLO should handle only python
> >   based activities(or activity should bundle all its dependencies)
> 
> Sorry, but I'm still a +1 for, "Activity should bundle all its needed dependencies, but try to work within the existing platform tool set". I understand it's not always possible, and your 0-install work may provide us a rather graceful way to support random, unexpected architectures or platforms (for the exceptions not the norm); but the last thing Sugar needs is to try and potentially support and run every bit of open source code out there. We should focus on well designed Sugar or Sugarised activities. Otherwise Sugar will loose all useful identity and we would might as well drop it and move over to some other random Linux distro.
> 
> For me, what makes Sugar special is its consist, system wide attempt to focus on a child centric, and learning centric design.
> 
> Regards,
> --Gary
> 
> P.S. FWIW: As a Mac OS X developer and user, I almost never have to worry about dependencies or packaging. Almost all OS X applications are self contained bundles, usually containing 'fat binaries' for 32, 64, PPC Intel architectures, and targeted at perhaps the last 2 or 3 OS X version releases (4-5yrs bit rot life time). I just mention this as a working mainstream example.

btw MacOS geogebra package weights 5M (doesn't bundle jre) :)

I guess we should ask ourself more generic question,

    How we should treat ASLO(and sugar itself)
    1) education platform
    2) python based education platform

Maybe I'm wrong and this question was already answered for others and
this answer is 2) but in my mind it was all time 1).

In case of 2) we will HAVE TO face packaging issues anyway since there
is lots of education software that could be proper sugarized (not only
running but adding Journal support for example).

Possible ways could be:

    bundle all dependencies
    but bundle 50M(if we include ARM support it will be 75M) for every
    java based activity looks overkill

    rely only on Sugar Platform
    but we can't include all possible dependencies
    
    deployment method when all efforts are concentrated around one(several)
    particular sugar distributions like OLPC or SOAS
    but I guess more global approach was chosen since organizing SL

    using more flexible scheme when we have
    * Sugar Platform and majority of fully bundled activities (since
      dependencies were included to SP)
    * minority which have non-SP dependencies, such dependencies could be
      * bundled, if they are small
      * installed on demand from native packaging systems
      * fetched on demand

    ..add your own..

-- 
Aleksey