01-12-2014, 04:56 AM
"Cannot connect to DB" is a regular error like any else. Yes, it shouldn't propagate further, but you cannot stop plugin writers from writing such faulty plugins.
I think dependency should be explicitly stated for plugins in their Info.lua file, rather than only inside by the API they use.
And my approach even allows for circular dependencies, because the dependency is specified as late as possible - only when it is actually needed, rather than beforehand.
Consider that there might be multiple "Coiny"-style plugins. Now I want to develop a plugin that can talk to any of those (but don't need all at once). With your style it would mean that there's a hard dependency on each of them; while with my approach the dependency is soft - the one plugin that is called successfully is the one used.
There are multiple levels of dependency in MCS that we should consider:
- "Hard dependency" - the dependent plugin won't work without the dependee. As an example, a chest shop plugin depending on Coiny; without coiny there's no money, so nothing to provide shop value.
- "Soft dependency" - the dependent plugin may provide more functionality if the dependee is present. For example consider ProtectionAreas - WorldEdit interaction. ProtectionAreas does work without WorldEdit, but if WorldEdit is present, you don't want WorldEdit-enabled users to vandalize protected areas.
- "Independent dependency" - There are types of plugins that need to be loaded in a specific order in order to work properly. For example there's a ChatLog plugin and there's ChatColor plugin. Loading ChatColor before ChatLog produces garbage chat-coloring codes in the server console log. The plugins don't have any code-specified dependency, though.
- "Cosmetic dependency" - the webadmin looks the best if the Core is loaded first
Another dependency point that your approach doesn't solve anyway is the order of hooks: If a plugin needs to register its hook before another plugin (like in the ChatLog / ChatColor example above, let's pretend they do specify their dependency in code), the plugin could register its hooks and only then try to load the dependee, which means the hooks will still be registered in the wrong order.
I think dependency should be explicitly stated for plugins in their Info.lua file, rather than only inside by the API they use.
And my approach even allows for circular dependencies, because the dependency is specified as late as possible - only when it is actually needed, rather than beforehand.
Consider that there might be multiple "Coiny"-style plugins. Now I want to develop a plugin that can talk to any of those (but don't need all at once). With your style it would mean that there's a hard dependency on each of them; while with my approach the dependency is soft - the one plugin that is called successfully is the one used.
There are multiple levels of dependency in MCS that we should consider:
- "Hard dependency" - the dependent plugin won't work without the dependee. As an example, a chest shop plugin depending on Coiny; without coiny there's no money, so nothing to provide shop value.
- "Soft dependency" - the dependent plugin may provide more functionality if the dependee is present. For example consider ProtectionAreas - WorldEdit interaction. ProtectionAreas does work without WorldEdit, but if WorldEdit is present, you don't want WorldEdit-enabled users to vandalize protected areas.
- "Independent dependency" - There are types of plugins that need to be loaded in a specific order in order to work properly. For example there's a ChatLog plugin and there's ChatColor plugin. Loading ChatColor before ChatLog produces garbage chat-coloring codes in the server console log. The plugins don't have any code-specified dependency, though.
- "Cosmetic dependency" - the webadmin looks the best if the Core is loaded first
Another dependency point that your approach doesn't solve anyway is the order of hooks: If a plugin needs to register its hook before another plugin (like in the ChatLog / ChatColor example above, let's pretend they do specify their dependency in code), the plugin could register its hooks and only then try to load the dependee, which means the hooks will still be registered in the wrong order.