[IAEP] ASLO

[Dave Crossland]

On Jul 14, 2016 8:15 AM, "Sam Parkinson" <sam.parkinson3 at gmail.com> wrote:
>
>
>
> On Thu, Jul 14, 2016 at 10:01 PM, Dave Crossland <dave at lab6.com> wrote:
>>
>>
>> On 14 July 2016 at 07:13, Sam Parkinson <sam.parkinson3 at gmail.com> wrote:
>>>
>>> What do you mean?  ASLO is based on very old technology, which is going
to get broken.
>>>
>>> 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.
>>
>>
>> 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.
>
>
> Nice idea.  That is very simple!  But remember that you also needs
search,

As a single page the browser search provides that. Site wide Google Search
provides that.

> i18n,

Its static content. i18n can be done inline.

> provide an api for Sugar to get list of bundles to update.

What is the current api URL schema and do we have examples of sample data
or do we need to bring aslo back up?

Jekyll can provide structured data in html, XML, json, etc.

> The current ASLO also has other features, like a developer interface (how
do devs submit updates to the static site)

Github pull request.

> and only showing the user activities that are compatible with the version
of Sugar they are running.

They click the version and a <10 line JavaScript script hides the
irrelevant information.

>>> 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?

Salut could just be stable. The spec is at least a decade old. Telepathy
and Gabble might be lost causes.

> 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.

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?

> Telepathy seems much more complex than Sugar needs - we don't need
abstract multi-backend support.

What are examples of Activities that deeply integrated collaboration? Write?

>> I think we should not upgrade to python3 but javascript.
>
>
> Py2 -> Py3 is a small change.  Py2 -> JS is massive.

The return on investment is the same, though.

> 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)

Lionel already has real time collaboration working on Sugarizer, this is no
biggie.

> What do you mean by javascript?  It is javascript and HTML?  Or
javascript on top of GJS, using the same amazing Gtk+ technology stack?

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.

> 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.

If we want to provide software for all the world's children we must develop
software that runs on all platforms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20160714/189e7ddc/attachment.html>