[Sugar-devel] Proposal to build app store for python 3 activities
sumitsrisumit at gmail.com
Sun Apr 12 13:34:03 EDT 2020
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>
> 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
>> those (if any) written in other languages. Based on user-agent we can
>> - Sugar OS - all activities including JS written for Sugar and
>> - 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.
>> Apr 12, 2020, 01:18 by sugar at radii.dev:
>> Hello everyone,
>> I wish to build app store for python 3 activities
>> 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
>> 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.
>> - 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
>> - Sugar will use app store to automatically upgrade newer version of
>> 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.
>> - 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.
>> - *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
>> - *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
>> - 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.
>> - 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).
>> update page dynamically.
>> - 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.
>> - 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
>> 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.
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel