gngr
gngr copied to clipboard
gngrOrg
ExtensionManager Rewrite
Rewrite the ExtensionManager stuff to load plugins similar to the way that Bukkit does it does it with org.bukkit.plugin.Plugin, that might be easier than our current way of dealing with extensions being in the ext folder.
https://github.com/Bukkit/Bukkit/tree/master/src/main/java/org/bukkit/plugin
gngr retained the ExtensionManager in order to enforce its security policy. (The policies in SecurityManager are enforced based on the protection-domain of a class, which in turn is defined by the class loader of that class. Most class loaders define it to the URL base from where the class was loaded.)
Hence, in its current form, ExtensionManager is more like a library manager. Only the PrimaryExtension is an actual extension.
This code can probably be rewritten to make things clear, but I don't want to change the underlying requirements.
I don't know what's special about Bukkit's plugin system, and how it would fit into our requirements. Can you please elaborate?
Yes, if we rewrite the extension manager we can retain the security policy stuff. By rewriting the way the ExtensionManager works we can allow extension developers to hook into the browser easier. We would be able to do things such as implementing onLoad, onEnable methods, which developers can use to register permissions needed to hook into the browser, ex: an ad blocker would need permission to modify html output.
The bukkit plugin system uses yaml config files, and creates a directory for the plugin to store data ex: config.yml, which if we added that concept to the browser, it would allow developers to store basic data in the extension's data folder using yaml. We would also be able to add things such as event executers, and error handling to detect invalid extensions.
Ah! Third-party extensions are very low on the list right now. We are not sure we want to allow them at all.
Our current goal is completing support for CSS2.1. Without that, the browser is not practical to use on most websites.