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

[Tomeu Vizoso]

On Sat, Jun 20, 2009 at 21:09, Jonas Smedegaard<dr at jones.dk> wrote:
> -----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.

Yes, I don't really understand why you are surprised.

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

This may change in the future if available disk space grows faster
than the size of development packages, though we may also decide to
include more platforms for developing Sugar activities like Java, etc.

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

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

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

I agree with what you have written above, I don't understand what we
are discussing ;)

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

Regards,

Tomeu

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