[Sugar-devel] Bundles with binary requirements (Was: The ARM is near)

[Gary C Martin]

Hi Aleksey,

On 30 Aug 2009, at 01:23, Aleksey Lim wrote:

> On Sun, Aug 30, 2009 at 12:51:22AM +0100, Gary C Martin wrote:
>> On 30 Aug 2009, at 00:17, Aleksey Lim wrote:
>>
>>> On Sat, Aug 29, 2009 at 05:09:44PM -0400, Michael Stone wrote:
>>>> 0install looks quite promising to me and
>>>>
>>>> http://www.osnews.com/story/16956/ 
>>>> Decentralised_Installation_Systems
>>>>
>>>> is good reading about the general issues involved.
>>>>
>>>> Has anyone here experimented with it?
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>
>>> Yeah, I like 0install(or its concept) more and more.
>>>
>>> In our case it could solve several issues at once:
>>> * lack of sugar packages for non-mainstream distros, we could  
>>> provide
>>> 0install sugar packages in "click to install" form for any user
>>> * arguable questions about what new dependencies we should add to
>>> Sugar
>>> Platform(e.g. java, Qt, webkit etc.), if activity uses these non
>>> Sugar
>>> Platform dependencies, just add add them to your activity as  
>>> 0install
>>> dependencies(or so)
>>> * binary blobs in activities, all dependencies will be fetched by
>>> 0install
>>> we have lightweight .xo bundles and external dependencies could be
>>> reused by several activities
>>> * dependencies between several activities could make sense in some
>>> cases
>>> e.g. TamTam's common resources(10M) could be fetched as
>>> dependency for
>>> TamTam activities(now each activity has separate copy of common
>>> resources)
>>>
>>> If there is no interested in people I'll try it after 0.86 release.
>>
>> It is interesting, but fails horribly badly in the case of no, or
>> low bandwidth Internet. Just imagine the mess when some school on a
>> low bandwidth high cost satellite link downloads "Wibble
>> Activity.xo" and pops it on there local server, or perhaps kids
>> themselves start to share the bundle, or distribute it on a USB
>> stick from one to another. Think of all those extra nasty yes/no/are
>> your sure dialogues, and subsequent download failures and support
>> calls, and the school or districts bandwidth budget...
>>
>> No insult or disrespect to the original developer, or those trying
>> to make it an activity, but the latest example
>> http://code.google.com/p/sarynpaint/ is an extremely simple/basic
>> bitmap paint program written in Java, that would take less than a
>> day for me (and I am certainly no expert) to duplicate from scratch
>> in Python. Imagine the huge amount of bandwidth, and install
>> failures if this just got uploaded in ignorance of all the duplicate
>> dependancy downloads this would impose on remote communities.
>>
>> Do you want a hand full of activity developers to bare the time
>> effort and cost of producing a quality, efficient, well thought
>> through and designed activity? Or put that cost on to 100,000+
>> children and their country school systems? How many ebooks could you
>> distribute (and store) for the bandwidth (and nand space) taken up
>> by downloading the required dependancies for Java. And once such a
>> download system is in place, what will be the next unsupported
>> language someone will try to ship an activity in?
>>
>> Apologies for the rant.
>
> hmm.. or I didn't get what you mean or you are messing several  
> things..
> * writing one day sugar activity in java instead of python soungs
>  useless,

Sorry if I wasn't clear but I meant 'spend one day writing that  
particular activity in Python instead', and avoid the whole 'how do I  
ship a full Java runtime' for this simple paint app (again no offence  
intended to those involved in this specific case).

> but we can't say Use python or your code won't be sugar
>  blessed because your favorite language is not included to Sugar
>  Platform

Actually that is *exactly* what we should be saying, otherwise the  
whole point of having a streamlined blessed platform tuned to reaching  
Suagr Labs mission is a pointless exercise. What you leave out is as  
important as what you put in.

> * case of no or low bandwidth Internet is the common question and
>  could be resolved until we will deploy sugar by Holy Spirit instead  
> of
>  wires, we have this problem now(since we use ASLO) and will have
>  this problem in the future at the same time this problem could be
>  solved now and in future environment by using local servers(or so)

If a bundle contains all code an activity needs to run (excepting code  
available in the Sugar Platform), then individuals/deployments can see  
up front the requirements of an Activity when they make the decision  
to download it. When they then share, distribute, and or modify that  
Activity (another Sugar goal) locally to others (potentially off- 
line), there is no additional external dependancy checks and download  
magic needed, everything is in that bundle that the author intended.

At the point where we discover we have suddenly N activities all  
independently using the same library, we can lobby the community to  
have that library included in the next future release of the platform.

Regards,
--Gary