GSoC 2019: Plugin Manager (Week 3)

The third week's work still focuses on the fetching routine for plugins stored on musescore.org.

What I have done

1. Improvements on the scoring algorithm
   The scoring algorithm, briefly described in last week's blog, gives a score for each matched link found within the plugin detail page, to indicate how much likely it is to be the suitable download address.

   Before, only the filename was used to estimate scores. Now, multiple pieces of info are used via the following approach:

   First, the filename(i.e., the IV part in the picture) is analyzed, and if nothing valuable(like "3.x" or others) is found, go on to look in the whole line(i.e., the I and II part). If no version info is found again, go on to search in the last line(i.e., the III part), if there's not another matched url residing in that line.

   I would understand if you find the above hard-coded scoring rules looking stupid and inflexible, but I believe the rules could greatly improve the accuracy indeed, since I've observed that most existing plugins follow these rules.

   Some simple tests have been made. For pages like https://musescore.org/en/project/tin-whistle-tablature, https://musescore.org/en/project/tunings-and-temperaments and many others, the auto-updater is now able to accurately choose the 3.x version.

2. Refactoring the codes
   There has been the question: whether plugins from GitHub or musescore.org should be considered first. After the scoring algorithm is introduced, the issue can be resolved by scoring both attachments and GitHub links. I refactored the code so that all GitHub links and attachment links within the page are scored before a suitable URL is selected. Then the old GitHub/attachment download routine follows.

What to do next

• Continue to test and optimize...Hopefully the most difficult part in fetching plugins has been gone through already.

• Clean up the code and fix some warnings.

• Optimize the routine of checking for update.