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

[sugar at radii.dev]

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 <https://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 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 activitieswhich 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
> 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.
> 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.
> 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
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200412/4f5a3e6b/attachment.htm>