[IAEP] Fructose = Sugar essentials (was: ASLO Suggestion)
dr at jones.dk
Sat Jun 13 14:21:07 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.
Above looks like the environment required for developing Sucrose
Do you mean to say that an activity that contains C code linking
directly to e.g. GTK+ 2.16 is ok?
IMO well-behaving non-Fructose activities should only require Glucose.
I.e. to not bind directly to non-Glucose libraries or invoke any
>> 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
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
To me above sounds like a pretty exact description of an unstable ABI.
>> With your logic, activities that rely on non-Sugar libraries, like
>> TamTam, should be part of Fructose, as future releases of CSound
>> cannot be trusted to keep binary compatibility. Just to name a
>> single example.
>I think you misunderstood me but cannot see in which way. TamTam, as
>any well-behaved activity, relies solely on a released version of the
>sugar platform. They are free to follow or not the sugar release cycle.
Because there is a risk that due to its dependency on CSound, which
might change its ABI at some point in the future (similarly to xulrunner
has done recently), "when the platform updates, [...] the activity for
this release cycle won't work in the past releases and past versions
won't work in the last release cycle."
But ok - you specifically used evince and xulrunner as examples, and
CSound did somehow not fit in as alternative. So let me try a different
You wrote, that in you opinion "the only reason for an activity to be
part of Fructose is to be tied closely to the release cycle."
If someone writes another activity which needs xulrunner, should that
new activity then be part of Fructose too?
>> In my opinion *no* activities should be tied to the Sugar release
>> cycle. Instead, *all* Activities, Fructose or not, should strive to
>> be backwards compatible, but might fail to do so for various reasons.
>I would like them to be backwards compatible but we should accept the
>fact that some won't be. Right now I'm adding tabs to Browse and I'm
>not going to try to find a way to make it backwards compatible because
>I have a ton of other things to work on. If someone else has the time
>and will to do so, patches are welcome.
I am not pointing fingers at your work or the work of anyone else. I am
simply suggesting that backwards/forward compatibility not be the reason
for inclusion in Sucrose.
If you agree with me in that, then please elaborate on what you meant
earlier, as I then clearly got it completely wrong.
>> I agree with Gary on this (which you didn't comment on, Tomeu):
>>>> For me, the only reason for Fructose is for those Activities
>>>> considered an essential part of the Sugar platform, i.e without
>>>> Browse it's going to be tough to install other Activities, without
>>>> Read you won't be able to read documentation. Most Activities ended
>>>> up in Fructose because their developers were also 'core' developers
>>>> (those also working on the core Sugar platform), and they usually
>>>> needed specific Activities to actually test and exercise the
>>>> various features they were working on and integrating in Sugar.
>As I said, I disagree with the explanation that Gary gives about why
>activities are in Fructose, though I agree it's confusing. I don't
>have nothing against having a list of basic activities, but are some
>activities that are going to depend closely on the last released Sugar
>Platform and those being in Fructose is going to make things easier
Sorry, I cannot parse that last long sentence above. Could you perhaps
* 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)
-----END PGP SIGNATURE-----
More information about the IAEP