[Sugar-devel] [somos-azucar] Harmonic Sugar distribuition

[Aleksey Lim]

On Fri, Mar 16, 2012 at 08:08:46AM -0400, Walter Bender wrote:
> On Thu, Mar 15, 2012 at 1:17 AM, Aleksey Lim <alsroot at sugarlabs.org> wrote:
> > Hi all!
> >
> >
> > There is a private email thread about how distribution might be
> > organized within the heterogeneous systems that can be potentially used
> > for Sugar installations. The background is, how such distribution should
> > be formed. In my mind, such system is doomed to be based on community
> > oriented solutions. So, I decided to share my thoughts publicly
> > to discuss them.
> >
> > The system described below, should be finally implemented in Peru pilot
> > [1] program (for sure, it will take several years and will start with
> > pretty basic solutions). But, it shouldn't be treated as a local,
> > for Peru, solution. It is a pilot for harmonic system to share various
> > types of content (including activities) within the Sugar community.
> >
> >
> > It will be useful to clearly separate the content to provide:
> >
> > (1) System components
> >    Highly depends on hardware, packages that are provided, mostly,
> >    by someone else, i.e., upstream.
> >
> > (2) Sucrose
> >    Sugar itself and the minimal startup kit of activities to start
> >    exploring the rest of accessible content
> >
> > (3) Favorited activities and content
> >    The majority of activities and content that people in the field
> >    will use.  They are, at least, filtered by people (not upstream
> >    creators) who stamped them as stable and good, from edu pov, to
> >    start using as-is.
> >
> > (4) Universe activities and content
> >    The rest of content in the community. Might be new versions of
> >    (3) that are not yet favorited, new activities that might be
> >    included to (3), various kinds of experiments that, most likely,
> >    will not be included to (3).
> >
> > Common solutions:
> >
> > * (1) is entirely from upstream; GNU/Linux official repositories with
> >  system packages for regular desktops and system package (not sugar)
> >  for XO laptops from OLPC (as a hardware provider, not software);
> >  repositories should be LTS, systems in the field can't be updated too
> >  often
> >
> > * (2) is formed as singular project on OBS[2] (not OBS project per
> >  usecase) for every supported (for a long time, i.e., LTS as well)
> >  Sugar release; this OBS project is being built into a bunch of
> >  repositories with packages, basing on needs in the field, bunch of
> >  distros and arches; in other words, all people in the field,
> >  regardless their platform, use the same packages (but built for
> >  different platforms); in other words, something like
> >  Sweets Distribution[3]
> >
> > * (4) is basing on Sugar Network[4], as universal system for sharing
> >  various types of content that assumes not only online environments
> >  (not all users in the field have decent Internet connection);
> >  content creators, upload their creatures (activities, articles, books,
> >  etc) into Sugar Network; all these majority of content is accessible
> >  for all Sugar Network participants; more over, Sugar Network covers
> >  the full life cycle for this content: support for activities, feedback
> >  from users, sharing ideas/problems/opinions, sharing Journal objects
> >  created within uploaded activities, etc;
> >
> > * the previous point will make situation really messy; for that reason,
> >  (3) will take place; Sugar Network editors might pickup some content
> >  to make sure its quality is good enough for as-is usage; editing might
> >  be organized on several levels, i.e., particular deployment might
> >  deicide to apply some post-filters to the global Sugar Network
> >  content; such filtering might various from leaving it as-is to white
> >  and black lists;
> >
> > Some details:
> >
> > * (3) might occur not only in "passive" mode by staring some content,
> >  but also with:
> >  * reuse Sugar Network collaborative features to work with upstream
> >    creators to improve the quality
> >  * upload to Sugar Network improved versions of the content and make it
> >    favorited (if upstream is irresponsive)
> >
> > * (4) with Sugar Network will cover Activity Library (ASLO) features;
> >  it was made with intension, ASLO is limited in cases like:
> >  * no decent support for binary activities
> >  * no way to upload Journal objects created by activities
> >  * bad integration with Sugar Learning Environment (people need to open
> >    browse and login/register)
> >  * no way to support people's experiments, it handles only singular
> >    activity from original authors
> >  using Sugar Network doesn't exclude ASLO, the only thing, the focus
> >  should be switched form "mirroring ASLO on Sugar Network" to
> >  "mirroring Sugar Network on ASLO"
> >
> > * for activities, (4) means that users having (1) and (2), can start
> >  "some Sugar Network client", findout on of (3) or (4) activities and
> >  click it to launch; in 100% for (3) and sometimes for (4), system will
> >  downlad prebuilt binaries, on OBS, to launch on client side; some times,
> >  for (4), will be downloaded sources to built on client side
> >
> >
> > [1] http://wiki.sugarlabs.org/go/Deployment_Team/Peru/Puno
> > [2] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System
> > [3] http://wiki.sugarlabs.org/go/Community/Distributions/Sweets_Distribution
> > [4] http://wiki.sugarlabs.org/go/Sugar_Network
> >
> > --
> > Aleksey
> 
> Would the plan include using Sugar Network to eventually replace ASLO?

SN is designed to cover all ASLO's functionality (but in more useful
way). ASLO might function as long as it will be in use (with
synchronizing data, at least for activities themselves).

> Then we could have a much more integrated workflow for building
> databases of activity output around the activities
> themselves--something I think would be of real utility to teachers and
> learners.

That the one of major purposes behind SN - make regular Sugar users,
different kinds of, behaviour more concentrated and integrated to
Sugar Learning Environment and education process itself (at least SN
will provide technical basis for easy implement such features).

It can't be implemented basing on ASLO (old or new AMO codebase),
because of one major difficulty, I forgot to mention, it is online
service by design and can't be replicated on school server on a XO
at rural school in off-line environment.

-- 
Aleksey