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

[Sumit Srivastava]

I thought that you wanted to work on it regardless of GSoC.

Note that period to submit a new application for GSoC 2020 has passed.


On Sun, Apr 12, 2020, 10:59 PM Sumit Srivastava <sumitsrisumit at gmail.com>
wrote:

> 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/5e7e3a90/attachment-0001.htm>