IITCm: plugins manager

[johnd0e]

Currently IITCm plugins manager home-brew implementation does not handle plugins in proper way.

To follow docs plugins should be distinguished not by filename, but by pair @namespace+@name.

But as long as scripts are stored in filesystem, special handling needed for edge cases.

• two different files with same [@namespace @name] should be treated as same script, so only 1st file should be loaded, and rest - ignored (with warning message).
  • when installing new plugin - old file should be deleted (with confirmation)
• opposite situation: when installing plugin it may occur that file with same name already exist. But if plugins have different [@namespace @name] - added plugin should be saved changing name (silently).
• when updating: content downloaded by @downloadURL should be verified again. Update should be stopped if [@namespace @name] do not match, or @version is not same as stated in meta.js (previously loaded by @updateURL). Ref: #210 (part 2) See update notes below. Also, related issue: #327
• IITCm embeds standard plugins, and currently it wrongly relies on that their list is constant, and do not updates list in 'Plugins settings'. But in 'Developer mode' standard plugins (and main script) are variable, as also read from filesystem.
• Enabled/disabled state should be stored not for [filename], but for [@namespace @name]. Currently if we delete file of some enabled plugin - there will be excessive exceptions in console log.

Note: Currently IITCm also uses @id metadata field. It is often misinterpreted as some unique id, but in fact it is used ONLY in one case: as filename, when plugin is extracted from email attachment. I'd suggest to drop it in favor of some more obvious fields, such as @downloadURL

Related issue: #63

Update notes There is no update algorithm described neither in GM, nor it TM docs.

• Greasemonkey: https://wiki.greasespot.net/Metadata_Block https://sourceforge.net/p/greasemonkey/wiki/Metadata_Block/#updateurl
• Tampermonkey: https://www.tampermonkey.net/documentation.php#_updateURL

The only officially source - GM primer here: https://www.greasespot.net/2012/02/automatic-script-updates-come-to.html

Unfortunately, it does not have all the details, and as result - real implementations may vary (see also https://stackoverflow.com/questions/38023717/why-is-usage-of-the-downloadurl-updateurl-keys-called-unusual-and-how-do-they)

[HubertZhang]

I propose a new manager that responsible for managing script.

• The manager could contains several embedded versions of IITC.
• The manager should store all downloaded, imported scripts to a separate folder.
• The manager scans all scripts and keep these info in memory, e.g. [@namespace @name], @version, filepath
• The scripts are indexed use [@namespace @name] combination.
• The manager stores a list of such combinations of loaded plugins.
• The manager resolve a plugin by searching in following folders: inbox, selected-embedded-version

[johnd0e]

The manager could contains several embedded versions of IITC.

I propose something different: option to choose 'update channel', like in IITC-Button.

• we store locally only 1 set of files.
• if 'update channel' option's value changed - we download and replace whole set of files.

BTW, forgot to mention in description: we could work without storage permission.

[HubertZhang]

Yeah, I think the important part is providing and switching the base set of plugins.

For the permission, maybe we should check if IITCm works well on android 10 since it add sandbox for old apps

[johnd0e]

maybe we should check if IITCm works well on android 10 since it add sandbox for old apps

I'm pretty sure it works well. Why is it important?

May be I should explain what I mean: currently storage is needed to use external plugins, because IITCm writes them to external storage. But it could write the to own internal storage instead, without additional permissions.

[Aradiv]

Is there somebody working on this because this is a huge painpoint for plugin updates had it happen now multiple times that plugins where broken because the update process didn't check the server response before overwriting

[johnd0e]

@Aradiv https://github.com/IITC-CE/ingress-intel-total-conversion/labels/help%20wanted