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 <sumitsrisu...@gmail.com> wrote: > This seems awesome. > > On Sun, Apr 12, 2020, 6:36 PM <su...@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 su...@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@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel