[Sugar-devel] Proposal to build app store for python 3 activities

[Sumit Srivastava]

This seems awesome.

On Sun, Apr 12, 2020, 6:36 PM <sugar at radii.dev> wrote:

> Unified App Store
>
> Once the app store is built with all the specified requirements, we can
> with minimal effort turn it into the unified app store for all activities
> including python 2 (though all would be ported to python 3), JavaScript and
> those (if any) written in other languages. Based on user-agent we can
> decide:
>
>    - Sugar OS - all activities including JS written for Sugar and
>    Sugarizer
>    - Old Sugar OS - python 2 activities (was there any support to run JS
>    written activities?)
>    - All other - Sugarizer activities unless toggled to show all
>
> This combined with building native app store (again with minor
> modification to web app store) which is geared only towards students for
> searching, browsing, installing and uninstalling apps would provide single
> app store codebase for entire platform.
>
> Please provide your comments on the idea. If idea is supported by the
> community than I can work towards building it.
>
> Regards,
> Manish
>
>
> Apr 12, 2020, 01:18 by sugar at radii.dev:
>
> Hello everyone,
>
> I wish to build app store for python 3 activities
> <https://github.com/sugarlabs/GSoC/blob/master/Ideas-2020.md#sugar-app-store-for-python-3-activities-aslov4>.
> For this I would like to inquire exact requirements of the project from the
> mentors and community at large.
>
> Below is my current understanding of project. Please read through it and
> correct where these are wrong. After it are some questions to answer to
> further improve my understanding. Some of these are merely more elaborate
> rewording of requirements specified on website
> <https://github.com/sugarlabs/GSoC/blob/master/Ideas-2020.md#sugar-app-store-for-python-3-activities-aslov4>.
> It is meant to detect possible misunderstanding that I may have from
> reading very brief one-line requirements.
>
> After few responses for this mail, a draft requirements document will be
> mailed for feedback before final requirements specification.
> Objective
>
>    - The objective of app store is to provide a one-stop platform for
>    students to browse or search and download activities to their system. It is
>    expected than once the app store is built, students would not have to
>    search for activities over internet, on GitHub or on wiki and download from
>    there.
>    - Sugar will use app store to automatically upgrade newer version of
>    activities.
>
> Users of app store
>
>    - *Students*: search and browse app store for activities and download
>    them if not already installed.
>    - *Trusted developers*: add and modify activities to app store via SSH
>    and than check them on app store. These are trusted developers and not all
>    the developers. Their role would be similar to package managers for
>    distros. That is, most of the times, the developer who built activity would
>    not be the one who uploads it but request trusted developer to grant access
>    or upload themselve.
>    - *Sugar desktop environment/OS*: check for current version on app
>    store and if new version found than download and upgrade activities on
>    local machine.
>
> User-interface
>
>    - The user interface/frontend of app store would be catering to
>    students primarily and therefore must be built keeping them in mind rather
>    than developers. But developers would still use it (or not?), therefore
>    there would be some consideration of them and providing information
>    relevant to them such as version of app, size, detailed/complete release
>    note, website/link to repository, license etc.
>    - Special attention needs to be made towards user experience and
>    usability. Such as web app should be responsive, delightful to use by
>    students. For this, some artwork also needs to be built such as logo of app
>    store, button icons, background etc.
>
> Functionalities
>
>    - *Upload activities to app store using SSH*: Trusted developers with
>    access granted/account created for this specific purpose can upload
>    activities to app store and have parameters to specify such as markdown
>    supported detailed description of activities etc. but information which is
>    available in activity.info will not be asked/cannot be specified in
>    parameters while uploading, instead it will be processed directly by
>    parsing activity.info file.
>    - *Search box*: There will be a single search input field in which
>    user enters search query. Thee are no complicated search query features
>    such as selecting category, no. of entries per page etc. At backend, based
>    on query keywords either a) a simple keyword match is performed and results
>    are returned in order in which received. b) some search improvement
>    processing is done such as a rank based search prioritizing keyword matches
>    in activities tile over activities description. There will/will not (please
>    inform) functionality to sort search results based on activities last
>    updated or added, no. of downloads etc.
>    - *Redirect older Sugar to python 2 app store
>    <https://activities.sugarlabs.org/en-US/sugar/>*: Redirect only Fedora
>    18 or earlier version based Suger 0.112 or earlier version to
>    activities.sugarlabs.org. Suger 0.112 or earlier desktop environment
>    is not running on any other distribution other than Fedora 18 or earlier or
>    not needed to be checked for.
>    - *List activities*: There will be a category in browse section of app
>    store named “All activities”, using it user can browse through all
>    activities and not just in some specific activity.
>    - *Support for Sugar’s microformat software upgrade feature*: Embed
>    CSS selectors and HTML data on activity bundles page and activity bundle
>    list page, to allow microformats based Sugar software upgrade feature to
>    check and automatically update activities when new version available on app
>    store. Should there be a page listing all activity bundles where Sugar
>    software upgrade feature will check for updates or should I follow the same
>    tree structure as on wiki <http://wiki.laptop.org/go/Activities/> or
>    should there be a way to let know Sugar of dedicated page of each activity
>    bundle to check for update (but modification to activity.info is not
>    allowed)?
>    - *Content-Type*: When user downloading activity bundle from app
>    store, server sends Content-Type header in response with the content-type
>    of sugar activities that is:
>    - application/vnd.olpc-sugar for Sugar activity bundle (extension .xo)
>       - application/vnd.olpc-content for Sugar content bundle (extension
>       .xol).
>       - application/vnd.olpc-journal-entry for Sugar Journal entry bundle
>       (extension .xoj)
>       - application/vnd.olpc-journal-backup for Sugar Journal backup
>       files (extension .xob)
>
> There would not be any other file than .xo but better to have information
> for all file types used by Sugar in app store software.
>
>    - *Automatically update activities from activities repository
>    specified in activity.info <http://activity.info> file*: A standard
>    recipe/script is to be made for server/app store to periodically check for
>    newer release under ‘releases’ section of activities hosted on GitHub and
>    automatically create its bundle and add it to the app store. However, it
>    will not be done for all activities which specify its website/repository as
>    GitHub repository but only for those which are whitelisted by website
>    admin/trusted developers as trusted repositories for security reasons and
>    all GitHub repositories starting with https://github.com/sugarlabs/
>    i.e. hosted by Sugar labs organization.
>    - *Inform if activity is already installed*: Wherever on app store,
>    there will be download buttons for activities, A check will be performed if
>    activity bundles are already installed on system. If so, than download
>    button colour will be changed and “already installed” will be displayed
>    below it. But, user can still download it. This need to be accomplished
>    without modifying activities and should work for all activities available
>    on app store. So, options which rely on modifying app itself are out of
>    option but Sugar can be modified to support this functionality such
>    supporting something similar to getInstalledRelatedApps() in Android.
>    - *Download count*: Every activity bundle should display no. of times
>    it is downloaded. It should include download count of all previous version
>    as well.
>
> Development
>
>    - Use general database such as MySQL/MariaDB for storing all textual
>    data such as app title, description, author name etc. and use their
>    in-built search functionality to perform search (after sanitizing input).
>    - The website will not be using JavaScript to make requests and update
>    page dynamically.
>
> Constraints
>
>    - Activities itself won’t be modified including their metadata file
>    located at activity/activity.info in their source tree for supporting
>    any of the required feature. Request for modifying metadata should not be
>    made such as for adding detailed description and instead should be fetched
>    from their repository or options should be provided for specifying
>    description while uploading activity bundle via SSH.
>
> Security
>
>    - Only developers which have been provided access in advance can
>    upload activities to app store. Some may have admin access, so they can add
>    other developers as well. A simple CLI script should be provided to easily
>    add new developers and their access level as ‘can upload new activities’,
>    ‘can modify specified activity’ and admin access.
>
> Additional Questions
>
>    1. Developer uploading activities via SSH? Will access to uploading
>    activities be with few trusted developers (my assumption as of now) or
>    anyone can upload activities to app store once approved.
>    2. Future considerations: how far is the app store expected to grow in
>    future in terms of its scope and functionalities. What considerations
>    should be kept in mind if app store functionalities and codebase is
>    expected to be a lot bigger in future.
>    3. Is programming language to be used for backend is per-decided to be
>    Python or can be JavaScript as well? I am comfortable with using any of the
>    two. My suggested framework for Python is Flask and if JavaScript is used
>    than Express.js. I also suggest using MySQL database similar to aslo
>    <https://github.com/sugarlabs/aslo> for backend for storing and
>    looking up activities metadata but store activities bundles as normal files
>    on disk. Is their any reverse proxy used on server where it will be
>    installed such as Nginx or Apache?
>
> Please give your comments on these questions.
>
>
> Regards,
> Manish
>
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200412/98b8cdc2/attachment.htm>