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

[Jonas Smedegaard]

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

On Sat, Jun 20, 2009 at 07:41:32PM +0200, Tomeu Vizoso wrote:
>2009/6/13 Jonas Smedegaard <dr at jones.dk>:
>> On Fri, Jun 12, 2009 at 05:53:30PM +0200, Tomeu Vizoso wrote:
>>>On Thu, Jun 11, 2009 at 18:18, Jonas Smedegaard<dr at jones.dk> wrote:
>>>> On Thu, Jun 11, 2009 at 04:33:29PM +0200, Tomeu Vizoso wrote:
>>>>
>>>>>IMO, the only reason for an activity to be part of Fructose is to 
>>>>>be tied closely to the release cycle. For most activities this will 
>>>>>be a bad thing, but for some it's good. I think it's good for 
>>>>>activities that depend closely on some part of the platform, so 
>>>>>that when the platform updates, say, xulrunner or evince, the 
>>>>>activity for this release cycle won't work in the past releases and 
>>>>>past versions won't work in the last release cycle. Using the same 
>>>>>release cycle as the platform makes things much easier.
>>>>
>>>> I strongly disagree with above: Sugarlabs should provide a minimal, 
>>>> core, essential system, that other activities are supposed to rely 
>>>> on as sole platform.
>>>
>>>Agreed, that's 
>>>http://wiki.sugarlabs.org/go/Development_Team/SugarPlatform/0.84
>>
>> Above looks like the environment required for developing Sucrose 
>> itself.
>
>No, those are the components that developers can use for their
>activity and can expect to be available during runtime.

Wauw, that is news to me: The platform to _develop_ activities is 
different than the platform to _run_ activities.

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.


>> 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)

To allow activities to be portable across "implementations of Sugar" (to 
avoid the word "distribution" as has been discussed with SoaS).


>>>> Essentially you are saying (or I am reading into it) that Fructose 
>>>> activities are those relying on unstable/missing Sugar ABI.
>>>
>>>No, released stable versions of fructose activities rely on at least 
>>>the last stable version of Sugar Platform.
>>
>> It makes sense to me that you consider some Sucrose releases stable 
>> as a whole.
>>
>> It makes no sense to me, however, that you consider individual 
>> Fructose activities stable and at the same time you say that "when 
>> the platform updates, say, xulrunner or evince, the activity for this 
>> release cycle won't work in the past releases and past versions won't 
>> work in the last release cycle."
>>
>> To me above sounds like a pretty exact description of an unstable 
>> ABI.
>
>Gtk+ has stable ABI, but you cannot expect that the latest GEdit will 
>work in a past release of Gtk+.

Agreed. But that last part: "and past versions won't work in the last 
release cycle" is a different case, I believe.

It makes sense to me that new features are added to new releases of 
Sugar, and that the use of those features makes newer releases of 
activities not work with older Sugar releases.

But if older activity releases do not work with newer Sugar releases, 
then I would call it a broken ABI (and if a simple recompilation did not 
make the activity work either, the API was broken too).

Did I misunderstand you, or did I perhaps misunderstand the fundamental 
logic of the terms ABI and API?


>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?!?



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)

iEYEAREDAAYFAko9M/4ACgkQn7DbMsAkQLiJ5ACfbTftrJAmKMVx8Na1yZn5w2k0
Qf4AnjPfLbduROrrdtaxRNL0/8qo5CKw
=R1Mw
-----END PGP SIGNATURE-----