search

sugarlabs / aslo-v4

A simple app store for sugarlabs
https://v4.activities.sugarlabs.org
GNU Affero General Public License v3.0
7 stars 12 forks source link

Review needed #6

Closed srevinsaju closed 4 years ago

srevinsaju commented 4 years ago

@quozl, @Hrishi1999

srevinsaju commented 4 years ago

@quozl I moved the heroku app to another account where I have credits. It won't get exhausted for another 100 hours. :smile: , I would be glad if you could rerun the same tests

srevinsaju commented 4 years ago

Yes, presumably we can direct apache to detect the URL and redirect to the flask app. Or, as I said, the logic could be added to the update-aslo.php that we already have on the activities.sugarlabs.org VM.

I would like to keep the logic of update-aslo.php untouched. What I would rather do is, to move update-aslo.php to update-aslo.old.php and then tell the flask app to handle all the requests (as can be done now), and if the requested version is below 0.116, then run update-aslo.old.php else run the function to get the static rdf generated.

I can explain the function of the flask server to make it more intuitive

Also4 generator generated static RDF .XML files and saves them to the api folder and hosts them on the static server

Aslo4 server (flask) is only a redirecting agent, i.e. when the request asks for 0.116 or above, it sends a GET request to https://sugarstore.netlify.app/api/.xml and then returns the data as RDF with correct content type. If the request was not found, send a GET request to https://activities.sugarlabs.org/.../update-aslo.php and then return the response to the user.

The time for processing using PHP takes more than 1-2 seconds to complete

The time for processing using Flask takes less than 0.5 seconds to complete. Tested previously using Postman

quozl commented 4 years ago

@quozl I moved the heroku app to another account where I have credits. It won't get exhausted for another 100 hours. smile , I would be glad if you could rerun the same tests

Tested again, worked okay.

The Log-42.xo bundle had a different sha256sum to the bundle I made when the activity was released. It is important that the bundles be traceable, for security. I guess this was a bundle you made from a git tag; which means it wasn't a release by the activity maintainer, but a release by you. This is why I need to have the content derived from bundles rather than GitHub.

srevinsaju commented 4 years ago

Yea, agreed, it was a release by me on master. This should be fixed when it's deployed in sunjammer. Right now I am building all the activities from master. Once it's deployed on sunjammer, the sha256 should match with the bundle provided. Alternatively, I could checkout the latest tag, and then the sha256 would match. Will fix that today evening. Thanks for your review!!

srevinsaju commented 4 years ago

Hmm, I tried to apply a fix, but still the, sha256 sums do not match my local build and server build. Anyway, I have added a "build from .xo" option, I hope that would do.

srevinsaju commented 4 years ago

Closing this, as issues can be now created