<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    The problem is ASLO, our primary interface and support for our user
    community. <br>
    <br>
    If we are going the github route, we need to set up a means for
    updated versions of Activities to be made into bundles and installed
    on the ASLO repository. Presumably documentation (but no code) would
    be required to document a procedure to submit or update activities.<br>
    <br>
    In the case of ASLO, the code base is PhP. At one time, it was
    proposed to implement in Python using Django - following the lead of
    Mozilla. This apparently didn't happen. Jekyll is clearly a much
    better framework, it's website promises that installing Jekyll is
    sufficient to create a website. :)<br>
    <br>
    The 'crumbling to dust' applies to the code not Python. Any software
    needs support. Most of the original developers of the Sugar
    activities have moved on to greener pastures. We have activities
    that failed because they incorporated object code which was not
    recompiled for ARM. We have activities that failed because they were
    build with hulahop. We have activities that failed because they
    imported Abiword. I have not seen a single example of a Sugar
    activity that had to be updated because of Python 2.7. <br>
    <br>
    Tony<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 07/14/2016 02:47 PM, Dave Crossland
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEozd0w09qdJ9gxrrZDkCu6dk=xfh22qtFw4maiKe6jA37y4cQ@mail.gmail.com"
      type="cite">
      <p dir="ltr"><br>
        On Jul 14, 2016 8:15 AM, "Sam Parkinson" <<a
          moz-do-not-send="true" href="mailto:sam.parkinson3@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:sam.parkinson3@gmail.com">sam.parkinson3@gmail.com</a></a>>
        wrote:<br>
        ><br>
        ><br>
        ><br>
        > On Thu, Jul 14, 2016 at 10:01 PM, Dave Crossland <<a
          moz-do-not-send="true" href="mailto:dave@lab6.com"><a class="moz-txt-link-abbreviated" href="mailto:dave@lab6.com">dave@lab6.com</a></a>>
        wrote:<br>
        >><br>
        >><br>
        >> On 14 July 2016 at 07:13, Sam Parkinson <<a
          moz-do-not-send="true" href="mailto:sam.parkinson3@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:sam.parkinson3@gmail.com">sam.parkinson3@gmail.com</a></a>>
        wrote:<br>
        >>><br>
        >>> What do you mean?  ASLO is based on very old
        technology, which is going to get broken.<br>
        >>><br>
        >>> 10/10 would love to improve ASLO.  I actually did
        an "ASLO2" effort a while ago, although that failed for reasons
        that are documented on my blog.  I would be up for using a
        AppStream and PackageKit based stack to reinvent the activity
        store experience though.<br>
        >><br>
        >><br>
        >> I think if ASLO can't be resuscitated, something VERY
        simple - a set of XO files and a Jekyll-like simple HTML site
        that links to them - would best replace it. <br>
        ><br>
        ><br>
        > Nice idea.  That is very simple!  But remember that you
        also needs search, </p>
      <p dir="ltr">As a single page the browser search provides that.
        Site wide Google Search  provides that. </p>
      <p dir="ltr">> i18n, </p>
      <p dir="ltr">Its static content. i18n can be done inline.</p>
      <p dir="ltr">> provide an api for Sugar to get list of bundles
        to update.  </p>
      <p dir="ltr">What is the current api URL schema and do we have
        examples of sample data or do we need to bring aslo back up?</p>
      <p dir="ltr">Jekyll can provide structured data in html, XML,
        json, etc.</p>
      <p dir="ltr">> The current ASLO also has other features, like a
        developer interface (how do devs submit updates to the static
        site) </p>
      <p dir="ltr">Github pull request. </p>
      <p dir="ltr">> and only showing the user activities that are
        compatible with the version of Sugar they are running.</p>
      <p dir="ltr">They click the version and a <10 line JavaScript
        script hides the irrelevant information.  </p>
      <p dir="ltr">>>> Re Sugar using python2; a port to
        python3 was previously investigated as part of last years GSoC. 
        We can port it baring our telepathy-python dependency.  (FYI
        there has not been a commit for telepathy salut or gabble in the
        past 2 years.  Dead upstream?  </p>
      <p dir="ltr">Salut could just be stable. The spec is at least a
        decade old. Telepathy and Gabble might be lost causes. <br>
      </p>
      <p dir="ltr">> Still, there are so many bugs that affect sugar.
         10/10 would love to port collab to using something like
        Matrix.Org - the spec is *way* is more easy to understand than
        telepathy.  </p>
      <p dir="ltr">Yes matrix is very nice. However I don't know if it
        supports collaboration otself, I think we need a crdt library or
        something similar on top? Or was that the case with telepathy
        anyway?</p>
      <p dir="ltr">> Telepathy seems much more complex than Sugar
        needs - we don't need abstract multi-backend support.</p>
      <p dir="ltr">What are examples of Activities that deeply
        integrated collaboration? Write?<br>
      </p>
      <p dir="ltr">>> I think we should not upgrade to python3 but
        javascript. <br>
        ><br>
        ><br>
        > Py2 -> Py3 is a small change.  Py2 -> JS is massive.
         </p>
      <p dir="ltr">The return on investment is the same, though.</p>
      <p dir="ltr">> And moving to JS means you have to replace
        telepathy, for Py3, we can easily port the python-telepathy
        library ourselves (it is very small library)</p>
      <p dir="ltr">Lionel already has real time collaboration working on
        Sugarizer, this is no biggie.</p>
      <p dir="ltr">> What do you mean by javascript?  It is
        javascript and HTML?  Or javascript on top of GJS, using the
        same amazing Gtk+ technology stack?</p>
      <p dir="ltr">I am proposing sunsetting the python codebase because
        it is crumbling to dust before our eyes. The Sugar Python
        codebase could go back to being maintained by OLPC Inc and Sugar
        Labs become a web shop. It seems the new "OLPC Laptop" will be
        running vanilla Ubuntu. </p>
      <p dir="ltr">> One idea that had been in my mind recently is
        moving parts of sugar-toolkit-gtk3 to Vala or C.  In Vala/C, you
        can expose the objects via Gobject Introspection - meaning that
        they are accessible from Python{2,3}, Javascript, Vala, Perl,
        and probably more.  Don't know if it would be worth the barrier
        that it adds to development though.</p>
      <p dir="ltr">If we want to provide software for all the world's
        children we must develop software that runs on all platforms. </p>
    </blockquote>
    <br>
  </body>
</html>