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

quozl commented 4 years ago

Thanks. A quick review.

srevinsaju commented 4 years ago

@quozl

  • [x] frequent use of SugarLabs instead of our formal name Sugar Labs,

Thanks, I were probably confused between the two!

  • [x] missing copyright symbol (C) after the word Copyright in __init__.py and possibly other files; briefly you haven't applied the license in the way the license says to apply it, read COPYING carefully,

I will make sure to change everything to AGPLv3. Actually, AGPLV3 is a non-permissive license. I am not sure what's the motive behind the use of AGPL, my bad I missed them out

  • [x] also missing copyright symbol in README.md,

ok

  • [x] SAAS usually means "software as a service", please find a better name, ask for input, previously we had proposed a project "Sugar app store" or "aslov4",

I mentioned this to @free-libre-software, who told to use SAAS as an acronym for sugar activities app store. ASLOv4 would not make sense if activities.sugarlabs.org continue to be maintained. I had written to the mailing list the previous name suggesting a sweet name so that I could change them. (I am still suspicious if my emails are being delivered to everyone, smh)

ok, that was our first organization name. it went unnoticed. thanks for letting me know

  • [x] surprised there are so many repositories; couldn't this be done with just one repository?

on the mailing list I had given a minimal explanation of why I kept multiple repositories for a single project.

in case you do want to merge, let me know about it. I assumed developer who are interested in only working with JavaScript can lookup the static repository and push changes and do not get too disturbed if they find out that they need to learn python to contribute

  • [ ] surprised there is a separate GitHub org; new developers at Sugar Labs won't find this easily, couldn't it be a repository in the sugarlabs org?

Yes, it could be moved to sugarlabs, someone should take the initiative to fork it or transfer it. (I do not have enough privileges to create a repo or push changes). An organisation was created so that

I could have alternatively forked Manish's repo and made changes in branch and ask Manish to review and merge, but unfortunately for approx 1 month, I am not having any response, so development declines and this project will not be eventually touched until a next GSoC.

  • [x] .gitignore has too much junk, even django,

😁 I guess Manish used a .gitignore template. I will write it from scratch.

  • [x] setup.py says this is GPLv3 and MIT, but COPYING is AGPLv3, quite a bit of disagreement there,

Hmm, my mistake again. I copied some sources fromy previous projects. I will correct them as soon as possible.

  • [x] "Sugar Bundle XOs" should be "Sugar activity bundles *.xo",

thanks, I will update them

(I will address the remaining comments in a separate comment 😅)

srevinsaju commented 4 years ago

@quozl

Minimum Requirements;

rsync -r path/to/bundle.xo xx@192.168.xxx.xxx:/foo/bar 
ssh xx@192.168.xxx.xxx:/foo/bar  -f 'saasbuild -i /foo/bar -fsvbguy -x activities.sugarlabs.org

Optional requirements;

Non-requirements; things we don't want to have to do;

Project Scheduling;

Coding Mentors
James Cameron, Hrishi Patel and, Rahul Bothra (via mailing list)

Btw, things might take time. This is only a initial release which Just Works™. I am not an internship student devoting full time to Sugarlabs Appstore developement, so expect dragons during a build :sweat_smile:

I assure you all of the requirements and optional requirements will be completed before the release v1

So far 7/11 of the requirements have been completed. I am not sure if its a good score. Is it?

srevinsaju commented 4 years ago

@quozl Fixed 7 out of the review you had mentioned. The other things need discussions, lets find a time appropriate to discuss live.

quozl commented 4 years ago

Thanks. A quick review of repository as of 9566d4ac7be23b85ce82582a005f90cfe6a0390d;

quozl commented 4 years ago

I will make sure to change everything to AGPLv3. Actually, AGPLV3 is a non-permissive license. I am not sure what's the motive behind the use of AGPL, my bad I missed them out

I don't know either. You could either ask all authors to relicense, or we could live with it.

I mentioned this to @free-libre-software, who told to use SAAS as an acronym for sugar activities app store. ASLOv4 would not make sense if activities.sugarlabs.org continue to be maintained. I had written to the mailing list the previous name suggesting a sweet name so that I could change them. (I am still suspicious if my emails are being delivered to everyone, smh)

Don't let Manish's absence constrain choice of name.

I think aslov4 as a project name makes reasonable sense regardless of whether we continue to provide activities.sugarlabs.org as a server name. We could redirect sessions according to user agent.

  • [ ] surprised there are so many repositories; couldn't this be done with just one repository?

on the mailing list I had given a minimal explanation of why I kept multiple repositories for a single project.

We can have further discussion on this if you like; the people who need to clone and deploy this service are very few; systems administrators at Sugar Labs, and integrators in school systems, and making life difficult for them by using multiple repositories doesn't seem like a good idea, especially when there's no clear need for the files to be spread over several repositories. Future developers, if any, can find files using search or git grep. Split by implementation language doesn't seem necessary; I don't think a developer who only wants to work on one language is being serious about development. Optimise software layout for use, not for development.

  • [ ] surprised there is a separate GitHub org; new developers at Sugar Labs won't find this easily, couldn't it be a repository in the sugarlabs org?

Yes, it could be moved to sugarlabs, ...

@chimosky could move it to Sugar Labs and give permissions to you. But I'd like to see it in one repository before we do that, as moving many repositories is more work and prone to mistake than moving just one.

I could have alternatively forked Manish's repo and made changes in branch and ask Manish to review and merge, but unfortunately for approx 1 month, I am not having any response, so development declines and this project will not be eventually touched until a next GSoC.

Couple of things; there's a pandemic here and Manish may have more important matters to attend to, and there's no reason we will use a next GSoC for this given the good progress so far. I expect the idea will be struck off for 2021.

Minimum Requirements;

  • support activity bundles uploaded via ssh,
rsync -r path/to/bundle.xo xx@192.168.xxx.xxx:/foo/bar 
ssh xx@192.168.xxx.xxx:/foo/bar  \
-f 'saasbuild -i /foo/bar -fsvbguy -x activities.sugarlabs.org

Good, please add to README.md. Especially needed is a way to ensure saasbuild does not use any network resources as part of this step.

  • detect User-Agent of Fedora 18 systems running Sugar 0.112 or earlier, and redirect to activities.sugarlabs.org,

Not done. Not aware of how to do it. Will learn about it smile

Good.

  • provide a list of all activity bundles,

See this

No, I don't mean that, I mean the HTML5 generated content should have a list of all activity bundles. Not just a search.

  • provide activity bundle download, using the correct Content-Type,

I am not sure what it means, or how to do that

You can download from activities.sugarlabs.org to find the correct content-type in the server headers. Or you can look at aslov1 source code in PHP. We also have a mime type defined in people.sugarlabs.org apache2 configuration.

  • provide search of activity bundles (using title, description, or other keywords),

Done, using minisearch

Good that it is done. Not good that an external dependency was used. I'm yet to review that in detail.

  • support Sugar's microformat software upgrade feature in My Settings, (Sugar 0.116 is configured in data/org.sugarlabs.gschema.xml to use the AsloUpdater in src/jarabe/model/update/aslo.py which reaches out to a PHP script update-aslo.php, and will instead be configured to use src/jarabe/model/update/microformat.py),

No clue cry

Please review those source files, configure your Sugar test instance to use AsloUpdater, and see what it does.

Optional requirements;

  • for a specific list of activities, access the source repository and detect any change to a release tag (publish), create a bundle and extract release notes,

Automatically extracted and built on https://sugarstore.netlify.app/ and local releases can be downloaded from https://github.com/srevinsaju/sugar-activity-build/releases

Good. As I said before, I expect only a very small number of activities will be in this list; like the Fructose set. The biggest reason is that we won't want tag changes in GitHub to automatically change the version in the app store, (because of risk of breaking user systems), nor do we want to host an .xo file that is different to the one the activity maintainer released (because the bundle is no longer traceable). Control must remain with the activity maintainer, not an automated system.

  • display in Browse if an activity bundle is already installed, (requires integration between Sugar on the local system and the web app),

Hmm, need to work on it

Yes, the Browse activity will need a way to execute JavaScript that can discover what bundles are installed.

  • download counts,

Possible. Written about it in (my first email) to the mailing list (http://lists.sugarlabs.org/archive/sugar-devel/2020-June/058454.html)

Thanks. This is not a very important goal, since many deployments of Sugar are off the internet anyway.

  • graphic design, style and appearance,

I hope, this is good at least smile

My reason for putting this entry here is to remind us that graphic design, style and appearance are (a) optional, (b) the least of our worries. I don't yet see any graphic designers rushing to help us out.

Btw, things might take time. This is only a initial release which Just Works™. I am not an internship student devoting full time to Sugarlabs Appstore developement, so expect dragons during a build sweat_smile

I assure you all of the requirements and optional requirements will be completed before the release v1

Thanks for your work so far. I don't think you should worry about version numbers.

So far 7/11 of the requirements have been completed. I am not sure if its a good score. Is it?

It is good progress. There's nothing to measure it against. Don't worry about a score.

@quozl Fixed 7 out of the review you had mentioned. The other things need discussions, lets find a time appropriate to discuss live.

I'm quite limited in time to discuss live. I'm fine to keep working by mail, GitHub, or something else asynchronous.

srevinsaju commented 4 years ago

you embed MIT/X11 licensed code in termcolors.py, and progressbar; is this compatible with the AGPLv3?

Yes its compatible with AGPLv3. I am allowed to use MIT licensed software in a project licensed for AGPLv3

you're using an absolute link to a logo in README.md instead of a relative link, creating a dependency on GitHub,

Yes, you are right. Fixed it on 01cface

we call them "Sugar activities", not "Sugarlabs Activities", because Sugarizer also has activities,

Fixed on https://github.com/sugarlabs-appstore/sugarappstore/pull/13/commits/372e95aedaa349c8241b3b4972d92c7ca3a4f125

some use of Sugarlabs instead of our formal name Sugar Labs, especially in README.md,

Fixed on https://github.com/sugarlabs-appstore/sugarappstore/pull/13/commits/8f2ac8f7e3d9159964749b0da171517fa5d2677f

"Sugar Bundle XOs" should be "Sugar activity bundles *.xo", in README.md.

Fixed it somewhere :sweat_smile:, dunno the commit hash

srevinsaju commented 4 years ago

I don't know either. You could either ask all authors to relicense, or we could live with it.

Until we get a review from Manish, we will use AGPLv3 respecting his decision

Don't let Manish's absence constrain choice of name. I think aslov4 as a project name makes reasonable sense regardless of whether we continue to provide activities.sugarlabs.org as a server name. We could redirect sessions according to user agent.

Ok, for now I have renamed it to sugarstore-generator. I hope that would be okay

We can have further discussion on this if you like; the people who need to clone and deploy this service are very few; systems administrators at Sugar Labs, and integrators in school systems, and making life difficult for them by using multiple repositories doesn't seem like a good idea, especially when there's no clear need for the files to be spread over several repositories. Future developers, if any, can find files using search or git grep. Split by implementation language doesn't seem necessary; I don't think a developer who only wants to work on one language is being serious about development. Optimise software layout for use, not for development.

Yea, I agree, thanks. I have merged it together on #11. Yes, its likely only experienced developers would work on aslov4 if they would too!

Good, please add to README.md. Especially needed is a way to ensure saasbuild does not use any network resources as part of this step.

I will create an extensive documentation iterating through all the steps, It might take time, but I hope it would be worth the time.

detect User-Agent of Fedora 18 systems running Sugar 0.112 or earlier, and redirect to activities.sugarlabs.org, Not done. Not aware of how to do it. Will learn about it smile Good.

Ok, I am stuck here. I do not know how to do it. User-Agent is only giving me Linux, I have no clue what distro is being run on the system not I can get the desktop environment. I had a small discussion with @Hrishi1999, please let me know how to do it, I am lost.

provide search of activity bundles (using title, description, or other keywords), Done, using minisearch Good that it is done. Not good that an external dependency was used. I'm yet to review that in detail.

External dependencies are not always good. Its good in this case because,

Please review those source files, configure your Sugar test instance to use AsloUpdater, and see what it does.

Okay!

Good. As I said before, I expect only a very small number of activities will be in this list; like the Fructose set.

okay, this is unclear. Is the appstore dedicated only for a few activities or all activities?

The biggest reason is that we won't want tag changes in GitHub to automatically change the version in the app store, (because of risk of breaking user systems), nor do we want to host an .xo file that is different to the one the activity maintainer released (because the bundle is no longer traceable). Control must remain with the activity maintainer, not an automated system.

I automated the system and like it, because

Anyways, its upto you to choose between automation and manual deploy. sugarstore-generator is only a tool. I used it in a different way, you may use it in another. I agree, automation reduces responsibility of a maintainer. I would not have created an automated system for a another organization, say KDE, because it has many users, many developers who test K* software every day. Automation can have bugs. Automation may not be safe for the user.

Yes, the Browse activity will need a way to execute JavaScript that can discover what bundles are installed.

okay, need to see that too

My reason for putting this entry here is to remind us that graphic design, style and appearance are (a) optional, (b) the least of our worries. I don't yet see any graphic designers rushing to help us out.

Graphics is good! I like Graphic Designing. I always wonder why development at www-sugarlabs is not given much importance.

Thanks for your work so far. I don't think you should worry about version numbers.

Okay! :smile:

It is good progress. There's nothing to measure it against. Don't worry about a score.

Thanks a lot :smiley:

I'm quite limited in time to discuss live. I'm fine to keep working by mail, GitHub, or something else asynchronous.

Okay, async will do too.

I have made some more changes. My next goal would be to create an extensive documentation. Thats on my checklist.

I have merged the repos. In case @chimosky wants to fork it.

I agree @quozl, an organization is redundant. Once someone forks it to sugarlabs, I will move development there

Unrelated: Development might slow down for a while. I am moving my repositories to GitLab because its cool. I am enjoying the mirror feature! :space_invader:

srevinsaju commented 4 years ago

PS: Comments are growing longer in size :joy:

quozl commented 4 years ago

Thanks. Briefly reviewed again.

quozl commented 4 years ago

I don't know either. You could either ask all authors to relicense, or we could live with it.

Until we get a review from Manish, we will use AGPLv3 respecting his decision

Some licenses wouldn't need Manish to approve, as it would be a derivative work. But the context of this discussion about the license was that you weren't sure why AGPLv3 was chosen. We are agreed we don't know.

Don't let Manish's absence constrain choice of name. I think aslov4 as a project name makes reasonable sense regardless of whether we continue to provide activities.sugarlabs.org as a server name. We could redirect sessions according to user agent.

Ok, for now I have renamed it to sugarstore-generator. I hope that would be okay

What was your objection to aslov4? I didn't quite understand it.

We can have further discussion on this if you like; the people who need to clone and deploy this service are very few; systems administrators at Sugar Labs, and integrators in school systems, and making life difficult for them by using multiple repositories doesn't seem like a good idea, especially when there's no clear need for the files to be spread over several repositories. Future developers, if any, can find files using search or git grep. Split by implementation language doesn't seem necessary; I don't think a developer who only wants to work on one language is being serious about development. Optimise software layout for use, not for development.

Yea, I agree, thanks. I have merged it together on #11. Yes, its likely only experienced developers would work on aslov4 if they would too!

Thanks.

Good, please add to README.md. Especially needed is a way to ensure saasbuild does not use any network resources as part of this step.

I will create an extensive documentation iterating through all the steps, It might take time, but I hope it would be worth the time.

It is the most important documentation. It need not be extensive. I've re-read the README.md as of 5d0575ecad505cb89f9e9b64935f1842cf628816 but don't know how to use the software to make a searchable list of activities from a set of bundles.

detect User-Agent of Fedora 18 systems running Sugar 0.112 or earlier, and redirect to activities.sugarlabs.org, Not done. Not aware of how to do it. Will learn about it smile Good.

Ok, I am stuck here. I do not know how to do it. User-Agent is only giving me Linux, I have no clue what distro is being run on the system not I can get the desktop environment. I had a small discussion with @Hrishi1999, please let me know how to do it, I am lost.

I don't know. You're going to have to find out yourself. I'm not here to explain everything to you. However, please look at the Browse activity source code and you'll see how User-Agent is set in the request headers to include the version of Sugar, and look at aslov1 and you'll see how the version of Sugar is extracted from the request headers and used to select what activities to show. This is a fundamental compatibility check; activity authors release activities with a list of compatible Sugar versions, at the time they are uploaded to aslov1, and then a child using Browse to search aslov1 for activities is only given those that are known to be compatible. I don't know how to extract User-Agent from within JavaScript, but unless you are doing it in Browse you won't be seeing the Sugar version. I don't even know if the JavaScript has access to the same User-Agent value that is appended to network requests. There may have to be added another way for Browse to share the information with a JavaScript program it is executing.

But the overall system features are important; if the version of Sugar being used is 0.112, then none of the Python 3 activities, for instance, should be shown, and the child should be redirected automatically or with a helpful message to the aslov1.

provide search of activity bundles (using title, description, or other keywords), Done, using minisearch Good that it is done. Not good that an external dependency was used. I'm yet to review that in detail.

External dependencies are not always good. Its good in this case because,

  • it is a popular search library
  • Very easy to code on
  • Provides ranking (other libraries do not offer this features)
  • Provides Fuzzy Search
  • One time indexing
  • Less CPU usage

Well, it won't work where there is no internet, because you're using a cdn to deliver it. Same with a lot of the other JavaScript components.

I thought Manish's first attempt had a built-in search, but I'm not sure.

Good. As I said before, I expect only a very small number of activities will be in this list; like the Fructose set.

okay, this is unclear. Is the appstore dedicated only for a few activities or all activities?

Only a few. Just because an activity is on github/sugarlabs doesn't mean we'd want it listed. We have a lot of crap activities that none of us want to show to the children.

The biggest reason is that we won't want tag changes in GitHub to automatically change the version in the app store, (because of risk of breaking user systems), nor do we want to host an .xo file that is different to the one the activity maintainer released (because the bundle is no longer traceable). Control must remain with the activity maintainer, not an automated system.

I automated the system and like it, because

  • I can see very less Activity maintainers on Sugar Labs, maybe very less than two developers and GSoC students. GSoC students are not permanent maintainers of the activities, which leaves many good activities without a maintainer.

  • I found that, many activities do not build properly, and I started creating issues

  • Found out Pointillism was missing from the automated Appstore

  • Test Sugarstore generator is working over a wider range of activities (In case a build fails, I will be notified, and I can be sure something is gone wrong in the recent commits).

Anyways, its upto you to choose between automation and manual deploy. sugarstore-generator is only a tool. I used it in a different way, you may use it in another. I agree, automation reduces responsibility of a maintainer. I would not have created an automated system for a another organization, say KDE, because it has many users, many developers who test K* software every day. Automation can have bugs. Automation may not be safe for the user.

Glad you agree.

My reason for putting this entry here is to remind us that graphic design, style and appearance are (a) optional, (b) the least of our worries. I don't yet see any graphic designers rushing to help us out.

Graphics is good! I like Graphic Designing. I always wonder why development at www-sugarlabs is not given much importance.

You're conflating things.

Graphic design is one of the skills used in web site design, but it is also used in software design. We don't have graphic designers helping us at the moment with either of these. Think of all those activities with terrible icons.

Sugar Labs web site only needs to capture the attention of potential users of Sugar, Sugarizer, and Music Blocks. It isn't a playground for graphic designers. We need to keep in mind what it is for. It is not for making work for students. It is not for creating an inclusive community. We could be happy with just plain text in good layout, or a WordPress site.

I have merged the repos. In case @chimosky wants to fork it. I agree @quozl, an organization is redundant. Once someone forks it to sugarlabs, I will move development there

If you can't fork or move it yourself, ask one of the other users, like @chimosky, to do it. Having common agreement on a project name is probably a pre-requisite. At the moment you've only had opinions from Manish, yourself, and myself.

Unrelated: Development might slow down for a while. I am moving my repositories to GitLab because its cool. I am enjoying the mirror feature! space_invader

Sure, but we don't use GitLab yet.

PS Comments are growing longer in size

If this is becoming too complex for you, move specific problems into new issues.

At the moment, it's just you and I talking. We haven't seemed to engage anyone else at Sugar Labs, because (a) they are busy, (b) the repository is not in Sugar Labs org, (c) the project name doesn't meet expectations, (d) few people need the project (I'm just one person who needs it), (e) as the project began as a non-selected GSoC project idea it loses readers, and (f) your problems with sugarlabs.org alias and spam detection.

radiidev commented 4 years ago

A quick note: I am happy to relicense my work to any FSF approved license that may be more suitable to organization needs. I did sought feedback on license at the time of demoing prototype. Let me know any other matter related to me that might be holding back.

Great work :+1:

srevinsaju commented 4 years ago

Thanks for the review @quozl , will get into it shortly.

your problems with sugarlabs.org alias and spam detection. PS: I resent it to the mailing list a week ago too. @codewiz fixed the spam thingy. I hope my emails are still not going to the spam

srevinsaju commented 4 years ago

What was your objection to aslov4? I didn't quite understand it.

There is no objection. I (personally) do not like integers in entrypoints. I prefer python more than python3, like that. More or less, it was my personal preference. And I also preferred the tool to start with sugar. ASLO is not very intuitive for new comers / users. I took a poll among the Google Code In Participants 2019-2020 at Sugar Labs, they said that Sugar App Store is way better than aslov4 Or Sugar Activity Centre,

I would suggest the name of the tool to be collectively discussed. I am not writing to the mailing list for a while (I guess, I have repeatedly sent stuff to and fro the mailing list, it might be annoying to some developers). As you said, the community working on this project is very small.

I will mention a few, idk

@walterbender @chimosky @aperezbios @tchx84 @shaansubbaiah

Please suggest a name for the New App Store for Sugar Labs (aslo v4).

shaansubbaiah commented 4 years ago

That took quite a while to read o.o

Agree with that SAAS doesn't seem right, confuses with Software As A Service, and for some reason even with the SASS language.

I am also not fond of aslov4 as it took me quite a while to understand what it actually was. I guess something along the lines of Sugar App Store makes sense and kids can relate with the Apple app store and Google play store.

srevinsaju commented 4 years ago

Thanks for the review @shaansubbaiah. I agree with you!

srevinsaju commented 4 years ago

Lets mention few more names, @JuiP, @Saumya-Mishra9129, please read https://github.com/sugarlabs-appstore/sugarappstore/issues/6#issuecomment-654181244 and input your suggestions

srevinsaju commented 4 years ago

For information, to future readers: SAAS is no longer the original name of the tool. It has been changed temporarily to sugar-store

srevinsaju commented 4 years ago

I don't know. You're going to have to find out yourself. I'm not here to explain everything to you. However, please look at the Browse activity source code and you'll see how User-Agent is set in the request headers to include the version of Sugar, and look at aslov1 and you'll see how the version of Sugar is extracted from the request headers and used to select what activities to show. This is a fundamental compatibility check; activity authors release activities with a list of compatible Sugar versions, at the time they are uploaded to aslov1, and then a child using Browse to search aslov1 for activities is only given those that are known to be compatible. I don't know how to extract User-Agent from within JavaScript, but unless you are doing it in Browse you won't be seeing the Sugar version. I don't even know if the JavaScript has access to the same User-Agent value that is appended to network requests. There may have to be added another way for Browse to share the information with a JavaScript program it is executing.

@quozl Thanks, your pointer to Browse-Activity helped me! Addressed in #14

srevinsaju commented 4 years ago

A quick note: I am happy to relicense my work to any FSF approved license that may be more suitable to organization needs. I did sought feedback on license at the time of demoing prototype. Let me know any other matter related to me that might be holding back.

Great work +1

Thanks @free-libre-software

Saumya-Mishra9129 commented 4 years ago

Lets mention few more names, @JuiP, @Saumya-Mishra9129, please read #6 (comment) and input your suggestions

I agree with https://github.com/sugarlabs-appstore/sugarappstore/issues/6#issuecomment-654190782

I guess something along the lines of Sugar App Store makes sense and kids can relate with the Apple app store and Google play store.

Sugar App Store makes better first impression than aslo4. However Sugar Activity Center is also a good alternative if not Sugar App Store because it includes word Activity.

srevinsaju commented 4 years ago

@quozl I have updated the documentation to create a minimal appstore.

quozl commented 4 years ago

@free-libre-software wrote:

A quick note: I am happy to relicense my work to any FSF approved license that may be more suitable to organization needs. I did sought feedback on license at the time of demoing prototype. Let me know any other matter related to me that might be holding back.

Thanks. AGPLv3 is an acceptable license for Sugar Labs. I had no concerns with the license. I had concerns with other licenses being mixed in, and the license not being applied properly. @srevinsaju had concerns with the reason behind the choice of license. I had no answer to those concerns, and don't have concerns about the choice of AGPLv3 as long as the license is applied properly and legally.

quozl commented 4 years ago

your problems with sugarlabs.org alias and spam detection.

PS: I resent it to the mailing list a week ago too. @codewiz fixed the spam thingy. I hope my emails are still not going to the spam

Only you can test that, after asking others. Archives of mailing list so far show only two posts this month, and from my mail archives I can confirm that;

I didn't have any reply to make to the post that was received. I think much of what was said in the post that went missing has since been canvassed in this issue, so I won't try to reply to it now. Let me know if you have any outstanding questions from the missing post.

I suggest not using your sugarlabs.org alias; it is quite clearly inferior to your own mail address, and continued use of it for anything critical would be mildly irresponsible. :grin:

quozl commented 4 years ago

What was your objection to aslov4? I didn't quite understand it.

There is no objection. I (personally) do not like integers in entrypoints. I prefer python more than python3, like that. More or less, it was my personal preference. And I also preferred the tool to start with sugar. ASLO is not very intuitive for new comers / users. I took a poll among the Google Code In Participants 2019-2020 at Sugar Labs, they said that Sugar App Store is way better than aslov4 Or Sugar Activity Centre,

Thanks for sharing your preferences.

I would suggest the name of the tool to be collectively discussed. [...]

Let's not conflate. There's the service, and there's the tools we use to deliver the service. There's no reason for them to be the same name. We've always called the service an Activity Library. As it is in the context of Sugar, we call it Sugar Activity Library. I'm not proposing we change that. I'd like to see your tool generate HTML that says it is the, or a Sugar Activity Library.

Our user documentation doesn't really highlight the service. The service is shown to the user by some JavaScript on the Browse activity home page, and by the Sugar - My Settings - Software Update control panel when the AsloUpdater is enabled.

At one stage, people got tired of typing Activity Library or activities.sugarlabs.org and began to shorten it to aslo. We have source code repositories named;

So an aslo-v4 would not be out of keeping with that pattern. That's why I'd like to see it renamed. I think the name of the Python module can be different; something that expresses that the action being taken is to create an activity library from activity bundles; e.g. mkal. I don't think the module needs to be in PyPi; almost none of our modules are. So that removes the need to have the word sugar.

srevinsaju commented 4 years ago

your problems with sugarlabs.org alias and spam detection.

PS: I resent it to the mailing list a week ago too. @codewiz fixed the spam thingy. I hope my emails are still not going to the spam

Only you can test that, after asking others. Archives of mailing list so far show only two posts this month, and from my mail archives I can confirm that;

* [this post went missing](http://lists.sugarlabs.org/archive/sugar-devel/2020-July/058511.html),

* [this post was received](http://lists.sugarlabs.org/archive/sugar-devel/2020-July/058513.html).

I didn't have any reply to make to the post that was received. I think much of what was said in the post that went missing has since been canvassed in this issue, so I won't try to reply to it now. Let me know if you have any outstanding questions from the missing post.

I suggest not using your sugarlabs.org alias; it is quite clearly inferior to your own mail address, and continued use of it for anything critical would be mildly irresponsible. grin

Thanks, it was probably my mistake. The moment I pushed the "Send" button, I remembered that I should have added the link to sugarstore.netlify.app when I am sending it to the mailing list. So, in the midway of sending the mail, I clicked "Cancel", and thats possibly why you didn't recieve the mail. But however, Sugarlabs Mailing List sent me a confirmation mail suggesting my mail has been received even though I did not completely send it. Possibly, it was only sent to the mailing list and I cancelled the sending of the mail before the mail was forwarded to you. Quite complex tragedy, and I was not able to add the link nevertheless. Conclusion: it was my mistake lol.

What was your objection to aslov4? I didn't quite understand it.

There is no objection. I (personally) do not like integers in entrypoints. I prefer python more than python3, like that. More or less, it was my personal preference. And I also preferred the tool to start with sugar. ASLO is not very intuitive for new comers / users. I took a poll among the Google Code In Participants 2019-2020 at Sugar Labs, they said that Sugar App Store is way better than aslov4 Or Sugar Activity Centre,

Thanks for sharing your preferences.

I would suggest the name of the tool to be collectively discussed. [...]

Let's not conflate. There's the service, and there's the tools we use to deliver the service. There's no reason for them to be the same name. We've always called the service an Activity Library. As it is in the context of Sugar, we call it Sugar Activity Library. I'm not proposing we change that. I'd like to see your tool generate HTML that says it is the, or a Sugar Activity Library.

Our user documentation doesn't really highlight the service. The service is shown to the user by some JavaScript on the Browse activity home page, and by the Sugar - My Settings - Software Update control panel when the AsloUpdater is enabled.

At one stage, people got tired of typing Activity Library or activities.sugarlabs.org and began to shorten it to aslo. We have source code repositories named;

* https://github.com/sugarlabs/aslo

* https://github.com/sugarlabs/aslo-v2-unused

* https://github.com/sugarlabs/aslo-v3

So an aslo-v4 would not be out of keeping with that pattern. That's why I'd like to see it renamed. I think the name of the Python module can be different; something that expresses that the action being taken is to create an activity library from activity bundles; e.g. mkal. I don't think the module needs to be in PyPi; almost none of our modules are. So that removes the need to have the word sugar.

Thanks. I prefer adding sugar- because some of personal preference again (not for publishing to PyPI) :smile:

I use Fish Completions. Whenever I wanted to do something, for example, to run sugar-activity3, I start typing sugar- and click TAB, to see possible completions. So prefixing it with something else would make it almost undiscoverable in my case. Moreover, considering I didn't know the name of the module. but I am sure I got it from sugar, and also I am a person who does this https://twitter.com/iamdevloper/status/1060067235316809729

image

also 

ls /usr/bin | grep sugar

is one of my approach of finding stuff, so you know !! :sweat_smile:

chimosky commented 4 years ago

I agree with the name Sugar App Store but as @quozl has mentioned, there's already a naming pattern for repos that have to do with storing sugar activities.

I also think that a domain name for Sugar App Store can be gotten that'll point to where we decide to store the activities but that's totally dependent on Sugar Labs, the name can also be at the home page of the app store.

NB: I haven't been able to look at any of the repos indepth but I'm interested in this and will take a look when I can.

srevinsaju commented 4 years ago

@chimosky thanks for your review! So what do you suggest as the name of this repository? Without the name, I guess I cannot make much progress. I have mentioned few developers at Sugar Labs at https://github.com/sugarlabs-appstore/sugarappstore/issues/6#issuecomment-654181244, but unfortunately only few responded. We are not in quorum to decide the name yet. I guess thats the max I can do as outreach. Maybe I can try asking a few more

@s-mag @kiy4h @AndreaGon @Creatune @pidddgy @sdziuda, I would be really grateful if you provide some feedback / suggestions proposing a name for the App Store (see https://github.com/sugarlabs-appstore/sugarappstore/issues/6#issuecomment-654181244)

quozl commented 4 years ago

So what do you suggest as the name of this repository? Without the name, I guess I cannot make much progress.

There's no reason to stop progress while a name change is pending.

quozl commented 4 years ago

Thanks, it was probably my mistake. The moment I pushed the "Send" button, I remembered that I should have added the link to sugarstore.netlify.app when I am sending it to the mailing list. So, in the midway of sending the mail, I clicked "Cancel", and thats possibly why you didn't recieve the mail. But however, Sugarlabs Mailing List sent me a confirmation mail suggesting my mail has been received even though I did not completely send it. Possibly, it was only sent to the mailing list and I cancelled the sending of the mail before the mail was forwarded to you. Quite complex tragedy, and I was not able to add the link nevertheless. Conclusion: it was my mistake lol.

I disagree. Your mail was received by the mailing list, was archived by the mailing list, and was sent out to the subscribers. I'm one of the subscribers. Other subscribers may have got it. It didn't arrive for me in my Inbox or Spam. Therefore my mail provider dropped it. Mail providers use heuristics and scoring. One of the important scores is the DKIM, which sugarlabs.org aliases don't support very well, last I heard. Nothing to do with your cancelling. I advise against using sugarlabs.org aliases until and unless that is fixed.

quozl commented 4 years ago

I use Fish Completions.

The tool is only going to be used by one to four people. It doesn't need to be in PATH or be subject to shell completions. If it were named mkal, then you'd run it by typing ./mkal perhaps. The ./ is much shorter than sugar-.

srevinsaju commented 4 years ago

I use Fish Completions.

The tool is only going to be used by one to four people. It doesn't need to be in PATH or be subject to shell completions. If it were named mkal, then you'd run it by typing ./mkal perhaps. The ./ is much shorter than sugar-.

Thanks for the info. I did not know that. I assumed the appstore is going to be deployed by other users of the sugar desktop / olpc laptop on their private servers. This solves the problem. Thanks for making it clear now, otherwise the discussion would have been prolonged without reason

quozl commented 4 years ago

Thanks. Being open source, there's no requirement for users of Sugar or OLPC OS to let me know if they are using it. :grin: I can say I helped make about three million laptops, many of which are still in use, but they run Python 2 activities and are using activities.sugarlabs.org and are unlikely to use this new service. I helped make a few thousand laptops that can run the Python 3 capable version of OLPC OS, but the statistics I have don't show a huge amount of users. Others make laptops and desktop computers, or buy them, and put Sugar on them, but we don't know much if anything about them.

srevinsaju commented 4 years ago

ok! I will proceed with refactoring. Makes things simpler and better I suppose :smile:

quozl commented 4 years ago

Thanks. Updated review checkboxes https://github.com/sugarlabs-appstore/aslo-v4/issues/6#issuecomment-654060887.

srevinsaju commented 4 years ago

@quozl updated https://github.com/sugarlabs-appstore/aslo-v4/issues/6#issuecomment-654060887 , please feel free to uncheck any if you find any other dangling instance

srevinsaju commented 4 years ago

@quozl I guess I need mentorship here. There is one important thing (and probably the last thing) remaining on the checklist

I was reading through the source code of AsloUpdater. I wanted to know a few things

Hope these questions are not too many. I could get back to work on this if I get some hints. :smile:

quozl commented 4 years ago
  • Where is the GUI part of the AsloUpdater 's source code located?

In the control panel for manual use, and it is also automatic. Here's the sequence;

  • Why does AsloUpdater appear on the Debian Virtual Machine and not on Sugar Runner? Does that mean, AsloUpdater can be selectively enabled / disabled?

It depends on the Gio.Settings? My guess is that Sugar Runner is different; I'm not maintaining Sugar Runner, so feel free to check the values of the setting schema.

  • Where is AsloUpdater getting the version of the installed activities? As activities.sugarlabs.org only has python2 activities, is there nay other place where its looking for?

By default it looks at activities.sugarlabs.org, see _UPDATE_PATH.

  • Can I completely rewrite the functionality of AsloUpdater?

For future versions, yes, but you have to keep in mind existing and previous versions which will have the older source code. However, it would be better to provide the same functionality as update-aslo.php, which generates a microformat RDF you can see in the comments, and you can run update-aslo.php by hand using wget to compare.

quozl commented 4 years ago

By the way, because SoaS does an update automatically and silently about ten minutes after startup, we've had some situations where test results differ between people testing SoaS depending on when they did the test.

srevinsaju commented 4 years ago
  • Where is the GUI part of the AsloUpdater 's source code located?

In the control panel for manual use, and it is also automatic. Here's the sequence;

  • extensions/cpsection/updater/__init__.py is the My Settings - Software Update control panel, and calls jarabe.model.update.updater,

Wow! Thanks. This is what I was looking for. This will help me to replicate a similar functionality from the function calls.

  • data/org.sugarlabs.gschema.xml defines org.sugarlabs.update backend which defaults to aslo.AsloUpdater class,

Should I change that and maintain a new file, eg: aslo.Aslo4Updater or edit the file in place and create a Pull Request?

  • OLPC OS sets backend to microformat.MicroformatUpdater, and sets microformat-update-url to a URL on our web servers, so as to release updates,

Ok

  • src/jarabe/model/update/updater.py manages the update process, see check_urgent_update and startup_periodic_update,

Hmm

  • src/jarabe/main.py schedules the update for about ten minutes after startup,
  • you can force an update by creating a file ~/.sugar-update, and this is checked when the network comes up after Sugar has started, which is the normal case for Sugar on a laptop; but not for Sugar on a virtual machine.

Ok

  • Why does AsloUpdater appear on the Debian Virtual Machine and not on Sugar Runner? Does that mean, AsloUpdater can be selectively enabled / disabled?

It depends on the Gio.Settings? My guess is that Sugar Runner is different; I'm not maintaining Sugar Runner, so feel free to check the values of the setting schema.

Ok thanks!

  • Where is AsloUpdater getting the version of the installed activities? As activities.sugarlabs.org only has python2 activities, is there nay other place where its looking for?

By default it looks at activities.sugarlabs.org, see _UPDATE_PATH.

Yes, but afaik, the activities on activities.sugarlabs.orf are python2, so comparing a python3 version of activity to python2 version is redundant now I guess.

  • Can I completely rewrite the functionality of AsloUpdater?

For future versions, yes, but you have to keep in mind existing and previous versions which will have the older source code. However, it would be better to provide the same functionality as update-aslo.php, which generates a microformat RDF you can see in the comments, and you can run update-aslo.php by hand using wget to compare.

I was wondering if I could use JSON. RDF looks slightly bloated, like, I mean the same information could be represented in JSON easily and smaller. I have no problem in creating RDF files on the server, but using JSON is easier than RDF considering I am hosting the site on a static site and not a server, (so I can't run PHP files :grin:)

quozl commented 4 years ago
  • data/org.sugarlabs.gschema.xml defines org.sugarlabs.update backend which defaults to aslo.AsloUpdater class,

Should I change that and maintain a new file, eg: aslo.Aslo4Updater or edit the file in place and create a Pull Request?

I don't know yet. That's something that will have to be designed. Put your DevOps hat on?

Re: checklist item Confgure AsloUpdater to use ASLOv4,

What the GSoC 2020 idea said was to support Sugar's microformat software upgrade feature in My Settings, (Sugar 0.116 is configured in data/org.sugarlabs.gschema.xml to use the AsloUpdater in src/jarabe/model/update/aslo.py which reaches out to a PHP script update-aslo.php, and will instead be configured to use src/jarabe/model/update/microformat.py).

  • Where is AsloUpdater getting the version of the installed activities? As activities.sugarlabs.org only has python2 activities, is there nay other place where its looking for?

By default it looks at activities.sugarlabs.org, see _UPDATE_PATH.

Yes, but afaik, the activities on activities.sugarlabs.orf are python2, so comparing a python3 version of activity to python2 version is redundant now I guess.

I don't see why we can't use activities.sugarlabs.org as the virtual host name provided that systems running a Python 2 version of Sugar are automatically and verifiably redirected to the Python 2 activities somehow.

  • Can I completely rewrite the functionality of AsloUpdater?

For future versions, yes, but you have to keep in mind existing and previous versions which will have the older source code. However, it would be better to provide the same functionality as update-aslo.php, which generates a microformat RDF you can see in the comments, and you can run update-aslo.php by hand using wget to compare.

I was wondering if I could use JSON. RDF looks slightly bloated, like, I mean the same information could be represented in JSON easily and smaller. I have no problem in creating RDF files on the server, but using JSON is easier than RDF considering I am hosting the site on a static site and not a server, (so I can't run PHP files grin)

No thanks. RDF is what we use now, and that you find it slightly bloated is inconsequential. Also, you can't upgrade the systems that demand RDF, so what's the point of breaking those systems or supporting both data formats?

You can run PHP files on activities.sugarlabs.org. That's how it works right now, if you use an HTTP client. You can run PHP if you have to on a system and have it write output to static site files. But I don't imagine you have to. The format doesn't look difficult to implement using Python.

srevinsaju commented 4 years ago
  • data/org.sugarlabs.gschema.xml defines org.sugarlabs.update backend which defaults to aslo.AsloUpdater class,

Should I change that and maintain a new file, eg: aslo.Aslo4Updater or edit the file in place and create a Pull Request?

I don't know yet. That's something that will have to be designed. Put your DevOps hat on?

Ok, I shall find a way then!!

Re: checklist item Confgure AsloUpdater to use ASLOv4,

What the GSoC 2020 idea said was to support Sugar's microformat software upgrade feature in My Settings, (Sugar 0.116 is configured in data/org.sugarlabs.gschema.xml to use the AsloUpdater in src/jarabe/model/update/aslo.py which reaches out to a PHP script update-aslo.php, and will instead be configured to use src/jarabe/model/update/microformat.py).

Yes I have read that. The demand was to create a static HTML and JavaScript operated Appstore. So I assumed sunjammer would not like to run server side processing.

  • Where is AsloUpdater getting the version of the installed activities? As activities.sugarlabs.org only has python2 activities, is there nay other place where its looking for?

By default it looks at activities.sugarlabs.org, see _UPDATE_PATH.

Yes, but afaik, the activities on activities.sugarlabs.orf are python2, so comparing a python3 version of activity to python2 version is redundant now I guess.

I don't see why we can't use activities.sugarlabs.org as the virtual host name provided that systems running a Python 2 version of Sugar are automatically and verifiably redirected to the Python 2 activities somehow.

Currently sugarstore.netlify.app redirects to the old activities.sugarlabs.org when an old version of Sugar is detected. I have no problem in using activities.sugarlabs.org, how would you suggest me to get started deploying aslo4 to sunjammer? Before that, I hope we could transfer this repository to Sugar Labs. @chimosky

I guess all the checklist items are completed other than configuring AsloUpdater which would require me to host a PHP server. Let me see where I can host a PHP server temporarily for testing (other than on my system) so that all can test and review. Heroku is a PaaS, maybe that would be useful

  • Can I completely rewrite the functionality of AsloUpdater?

For future versions, yes, but you have to keep in mind existing and previous versions which will have the older source code. However, it would be better to provide the same functionality as update-aslo.php, which generates a microformat RDF you can see in the comments, and you can run update-aslo.php by hand using wget to compare.

I was wondering if I could use JSON. RDF looks slightly bloated, like, I mean the same information could be represented in JSON easily and smaller. I have no problem in creating RDF files on the server, but using JSON is easier than RDF considering I am hosting the site on a static site and not a server, (so I can't run PHP files grin)

No thanks. RDF is what we use now, and that you find it slightly bloated is inconsequential. Also, you can't upgrade the systems that demand RDF, so what's the point of breaking those systems or supporting both data formats?

You can run PHP files on activities.sugarlabs.org. That's how it works right now, if you use an HTTP client. You can run PHP if you have to on a system and have it write output to static site files. But I don't imagine you have to. The format doesn't look difficult to implement using Python.

Ok, I don't mind using RDF too. I was implying how JSON is more readable to a user and also for processing. I will implement RDF. Thanks for the quick reply

srevinsaju commented 4 years ago

Ok, I have provided a solution for AsloUpdater.

compare

wget http://aslo4-server.herokuapp.com/update-aslo.php?id=org.laptop.Log&appVersion=0.116
wget http://aslo4-server.herokuapp.com/update-aslo.php?id=org.laptop.Log&appVersion=0.112
wget http://activities.sugarlabs.org/services/update-aslo.php?id=org.laptop.Log&appVersion=0.112

Suggested solution (any):

So far, the flask API has a few ms advantage over the PHP one, but I am not very familiar with writing PHP. Also, as there are many security concerns over PHP, I just decided to create a Flask server which would redirect to the necessary places. However, it looks possible to implement the same logic in PHP too, but I would need someone's help then, as it was not mentioned in the prerequisites

Please let me know if there is anything else to do; I guess I am almost done with the minimum requirements for the GSoC project. Feeling great :smile:

PS: It might take upto 40 seconds for the first request, because the Heroku server sleeps after an hour of inactivity. Deploying it to sunjammer might fix this problem

srevinsaju commented 4 years ago

Now optionally, I can add *Download count** feature in near future. (PS: feature in future; nice)

@quozl Ready for review! :tada: :tada:

srevinsaju commented 4 years ago

In case this ping was missed out, @quozl :smile:

quozl commented 4 years ago

Sorry, bit busy. You're still in the queue.

quozl commented 4 years ago

Yes I have read that. The demand was to create a static HTML and JavaScript operated Appstore. So I assumed sunjammer would not like to run server side processing.

Not so. Whether we run processing on sunjammer or not is unrelated to the requirement of generating static HTML with JavaScript.

quozl commented 4 years ago

Currently sugarstore.netlify.app redirects to the old activities.sugarlabs.org when an old version of Sugar is detected.

Thanks. I've tested that just now with Sugar 0.112 Browse 157.5, and the redirect does occur.

I have no problem in using activities.sugarlabs.org, how would you suggest me to get started deploying aslo4 to sunjammer?

I don't know, sorry.

Before that, I hope we could transfer this repository to Sugar Labs. @chimosky

We now have a fork in the sugarlabs org. Remember to keep it up to date?

I guess all the checklist items are completed other than configuring AsloUpdater which would require me to host a PHP server. Let me see where I can host a PHP server temporarily for testing (other than on my system) so that all can test and review. Heroku is a PaaS, maybe that would be useful

Better to update the existing update-aslo.php on sunjammer.

quozl commented 4 years ago

Ok, I have provided a solution for AsloUpdater.

compare

wget http://aslo4-server.herokuapp.com/update-aslo.php?id=org.laptop.Log&appVersion=0.116

503.

wget http://aslo4-server.herokuapp.com/update-aslo.php?id=org.laptop.Log&appVersion=0.112

503.

wget http://activities.sugarlabs.org/services/update-aslo.php?id=org.laptop.Log&appVersion=0.112

Good start, thanks.

Suggested solution (any):

Yes, for future release of Sugar, we can change this URL. We can't change it for existing builds of Sugar, that's why the old URL has to work as well.

  • Replace the update_aslo.php with a Python flask app on sunjammer.

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.

So far, the flask API has a few ms advantage over the PHP one, but I am not very familiar with writing PHP. Also, as there are many security concerns over PHP, I just decided to create a Flask server which would redirect to the necessary places. However, it looks possible to implement the same logic in PHP too, but I would need someone's help then

Great. Best person would be the authors of PHP manuals, I think.

, as it was not mentioned in the prerequisites

That it wasn't mentioned is unrelated to needing help. At the time we outlined the project, we didn't have a complete appreciation of what was needed.

Please let me know if there is anything else to do; I guess I am almost done with the minimum requirements for the GSoC project. Feeling great smile

PS: It might take upto 40 seconds for the first request, because the Heroku server sleeps after an hour of inactivity. Deploying it to sunjammer might fix this problem

Ok. I did repeat the wget after 40 seconds, but still 503.

srevinsaju commented 4 years ago

Oops, my bad. My heroku server credits ran out 

2020-07-28T06:07:38.896066+00:00 heroku[router]: at=info code=H82 desc="Free app running time quota exhausted" method=GET path="/update-aslo.php?id=org.laptop.Log&appVersion=0.112" host=aslo4-server.herokuapp.com request_id=92a12e82-8fa5-4687-bdbd-af0ded3a8fde fwd="1.144.109.17" dyno= connect= service= status=503 bytes= protocol=http

Free app running time quota exhausted : A problem with free PaaS's . I will move to another account where I have Cloud Credits, a try for the inconvenience.