On Thu, Mar 04, 2010 at 04:11:30PM -0500, Chris Ball wrote: > Hi Aleksey, > > > Can activity bundles on Activity Library [1] be not fully bundled > > and demand additional (except having .xo) steps (that in most > > cases will demand network connection) to its launch. > > Sounds like this should be a
> Development Team but it is mostly not Deployment Team case (afaik Development Team means core team) since requested changing affects general workflow. > Deployment Team * would be good to hear any feedback but I guess there weren't many of them * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users, in contrast, ASLO (afaik) is deployment agnostic > decision, unless you've already tried hard and failed to reach > agreement there. (Do you think that's the case?) > > Speaking as part of that Devel Team discussion (and not as a SLOB), > the current setup of not knowing beforehand whether a .xo bundle is a > complete activity or a partial activity is really hard to deal with. yup, proposed [1] could minimize disadvantages (of course it is not idela) with preserving fully bundled .xo and "links" to activities when users obviously know that it is a link and they (implicitly) need to download it > I think the current situation is very frustrating for anyone who is > downloading activities on a separate machine to the one they run them > from, such as XO users who depend on other people to download and > bring them activities with sneakernet. yup, it is an issue (but shouldn't be on current ASLO) but ASLO could provide (as a main download link) regular fully bundled .xo. The reason to have second downloading link on ASLO for "lightweight" activities is proper handling situation when there are several Java based activity and several version of each activity and user who has proper java installation. OLPC can add java to XO distro, not sugar if java could be added to Sugar Platform (because it should mean that *every* sugar box should have java) thus every .xo on ASLO will weight +50M (or after adding ARM, +75M), pretty useless if activity itself weights 5M. Another reason against bundling blobs is that we are trying to do pretty ugly thing to pass around GNU/Linux distributions efforts in over words ASLO uploader who bundles blobs will try guess what targeted environment would be. Keeping all these in mind, we can either stop bundling blobs(and say "Please do not upload java(e.g.) based activities to ASLO") or use something more reasonable then .xo. Both cases are better then current one when there is not any policy. > I think that these partial activities should not be used s/used/uploaded-to-ASLO/ I guess :) and it is also a way which is better then current, we just need to make it clear for other education projects that if they want to add sugar support to their projects, they need to request for inclusion theirs dependencies to Sugar Platform (but we can't add all debian repo to sugar dependencies, thus have to say "no" for some projects). > until we've > found a way to make their dependencies > (a) obvious to people who are > downloading the activity from ASLO not sure if I got it, dependencies could be bunch of .so like libxmls, libcairo etc. >, and (b) easily downloadable at > the time as the activity, to enable sneakernet downloading. and it could be done by in new scheme > > Thanks! > > - Chris. > -- > Chris Ball <c...@laptop.org> > One Laptop Per Child > [1] http://wiki.sugarlabs.org/go/Features/Zero_Sugar_Activities#Detailed_Description -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel