On Fri, Aug 28, 2009 at 07:02:30PM +0200, Tomeu Vizoso wrote:
On Fri, Aug 28, 2009 at 18:55, Jonas Smedegaard<d...@jones.dk> wrote:On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote:On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard<d...@jones.dk> wrote:On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote:If fat binaries are not desired, which alternatives do we have?1) Include more aggressively/liberally arch-dependent stuff in Sucrose, and include/write wrappers for popular arch-independent languages (e.g. Python) 2) Promote as "first class Activities" those written in arch- independent languages and depending only on stuff included in Sucrose.Both sound like good ideas to me,It was meant as a single alternative containing 2 steps.though 1) concerns more to deployers: do they want to have to install hundreds of megs of software that might or might not be used by any Sugar activities they get to use?Sucrose does not grow automatically. Sugarlabs maintains Sucrose, so gets to decide if it should bloat or if the author of an activity written in YACNL (Yet Another Cool New Language) is told to either rewrite in one of the existing supported languages or accept that the Activity will be a 2nd class activity due to the weird choice of language.I think that deployers should be the ones to say what can go in the platform and what not. But the more we have there, the easier it is for us developers.Could you give a concrete example of this dilemma (preferrably non-theoretical - i.e. tied to actual activities and languages currently used for them)?Let's say that a country wants to develop activities in java and have it as part of the platform. Maybe some other deployer with restricted disk space would be opposed to have to ship Java? Same with the cups filters, Mono, etc
Not a problem if the deplyer wants to extend locally with Java or some other bloat. Sugarlabs need not change the Fructose specs for that. The rest of the world need not suffer from such local oddities.
If, on the other hand, Sugarlabs choose to adopt all those cool activities created in Java, then Sugarlabs would bloat Fructose globally, and we would all suffer from the bloat. True.
But really such problem of Sugarlabs shooting itself in the foot like that is IMHO independent from the challenge of arch-dependent code in activity packages: If Sugarlabs wants the ability to make small-diskspace deployments then Sugarlabs must set the bar high for 1st class activities.
Oh, and in case we might be talking past each other due to terminology: I use the term "Fructose" as "the very minimal core set of stuff that must always be available for a system to sanely claim to run "Sugar".
I apologize for any confusion if I misunderstood the term. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
