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

[Jonas Smedegaard]

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

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.

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 
non-Sucrose commands.



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


>> 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 
example:

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

Sorry, I cannot parse that last long sentence above.  Could you perhaps 
rephrase?


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)

iEYEAREDAAYFAkoz7hMACgkQn7DbMsAkQLitDQCfZ6tVXGyV8XD5DydeSZRprlnX
BgQAn2ex/vR+zdGCmgKygJsPC4TSGahC
=Rqh8
-----END PGP SIGNATURE-----