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

[Gary C Martin]

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.