[Sugar-devel] Proposal to build app store for python 3 activities
sumitsrisumit at gmail.com
Sun Apr 12 13:29:30 EDT 2020
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).
> 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 be
> 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