-----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<[email protected]> 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----- _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
