[IAEP] Fructose = Sugar essentials (was: ASLO Suggestion)

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Sun, Jun 21, 2009 at 12:20:38PM +0200, Tomeu Vizoso wrote:
>On Sat, Jun 20, 2009 at 21:09, Jonas Smedegaard<dr at jones.dk> wrote:
>> Wauw, that is news to me: The platform to _develop_ activities is
>> different than the platform to _run_ activities.
>
>Yes, I don't really understand why you are surprised.

Because of my expectations of the awsesome goal discussed below :-)


>> I assumed that a working Sugar environment was supposed to be enough 
>> to take well-behaving Sugar activities apart and hack on them.
>>
>> Yes, I do know that the goal of supporting live editing activities by 
>> the learners have not been reached yet (except for a few Activities), 
>> but I still thought it was a goal - and pat of the vision with Sugar.
>
>That's an awesome goal, but distributors of Sugar like OLPC haven't 
>found a good way to ship all development dependencies in their space 
>constraints.
>
>Instead of throwing out the window the possibility of coding
>activities in C or whatever compiled language, we have decided to
>write as much as possible in an interpreted language like Python. It's
>a compromise.

That's why I talk about "well-behaving" activities.

I imagined a hierarchy of activities like this:

  0. Core activities (ideally none!) using non-Sugar libraries/binaries

  1. Well-behaving activities using only Fructose

  2. Other activities using whatever

With above distinction, users would be able to hack on well-behaving 
activities as they would all be written in a supported scripting 
language (Python now, perhaps Smalltalk/Squak or ECMAScript in the 
future).

And distributors (OLPC, SoaS, OpenSuSe etc.) could distinguish if they 
would offer a hackable subset or a larger hackable/non-hackable mixture.

And publishing mechanisms like ASLO could emphasize well-behaving 
activities.


>>>> Do you mean to say that an activity that contains C code linking
>>>> directly to e.g. GTK+ 2.16 is ok?
>>>
>>>Yes.
>>>
>>>> IMO well-behaving non-Fructose activities should only require
>>>> Glucose. I.e. to not bind directly to non-Glucose libraries or invoke
>>>> any non-Sucrose commands.
>>>
>>>Why so?
>>
>> To provide a well-defined, fully scriptable Sugar ABI/API (see above)
>
>But we already have that. I have the impression that you are seeing a 
>black or white situation where I'm seeing a black and white one. We 
>want _both_ the possibilities for writing Sugar activities in scripted 
>languages and in compiled languages.

See above.  I don't want to get rid of e.g. TamTam that is not written 
in Python.  But I do want such non-hackable activities to be treated as 
2nd class!


>> To allow activities to be portable across "implementations of Sugar" 
>> (to avoid the word "distribution" as has been discussed with SoaS).
>
>That's a nice goal, but we aren't currently aiming for it. Activity 
>bundles that contain binary code will have to contain versions for all 
>the platforms they want to run in.

I hope we simple misunderstand each other here:

I believe Sugarlabs _do_ want activities wo "just work", independent of 
the learner using a Sugar environment compiled on top of Fedora, Debian, 
OpenSuSe or whatever.

If Sugarlabs treat all activities the same, without encouraging those 
using only a "Sugar ABI" (which is *not* tied to a specific 
architecture, endianness or distribution), then alternatives like 
energy-efficient ARM or MIPS machines will be experienced as 2nd class.


>>>No activity _needs_ to be part of fructose. It's just a convenience 
>>>offered to activity authors that wish to use it.
>> [snip]
>>>The only reason for including an activity in Sucrose is because the 
>>>activity authors finds this release cycle convenient because of 
>>>synchrony with new releases of components like hulahop and 
>>>sugar-toolkit and because translators may have an easier time by 
>>>working on translations in one batch.
>>
>> Oh, now I am really confused:
>>
>> Any activity developer finding it convenient to follow the Sugar 
>> release cycle is welcome to have their activities included in 
>> Fructose?!?
>
>IMO, yes. I'm not the release manager and others have different views 
>of what Fructose means.

Bingo!  That is what I originally opposed, and still disagree with.

The rest of this longish thread was (important but) sidetracking.

As I see it, Fructose activities are non-hackable activities that are 
distributed to all learners.  So ideally there should be none, and most 
certainly the amount should be kept small.


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAko+GlEACgkQn7DbMsAkQLijQQCfejD7ATd/QT1szBjyVvzbW0gM
I3EAniPc8VmeHpK3GPL1h1ifmPk86ZVh
=B3P6
-----END PGP SIGNATURE-----