Differences

This shows you the differences between two versions of the page.

--- mantisbt:addson_requirements [2007/09/06 02:11] – Rename "Add-ons" to "Plug-ins", added "To Be Spec'd" section vboctor
+++ mantisbt:addson_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1
@@ Line 205: / Line 205: @@
   * Detail the parameters sent to each of the events.
   * How are the plug-ins going to be distributed.
 ===== Feedback =====
 This is still in progress, but you are free to contribute ideas.
+   * (DGtlRift) I would say that in "Information about a plugin" there should also be:
+      * plugin version - could be used by a plugin manager to query if there is an updated plugin available from the plugin's website.
+      * minimum mantis compatibility version - verify that this plugin will actually work with this version of mantis.  I could picture as time goes on the new events, apis, etc could be introduced to mantis, which newer plugins would start using, but would be incompatible with legacy versions of mantis.
+   * (DGtlRift) I would also suggest that the "Information about a plugin" should be either in well known variables within #modulename#_constants_inc.php and if there are missing a mandatory constant, do not "load/register" the plugin.
+      * I'm also thinking that it may be easier to use a hash table to store the constants in #modulename#_constants_inc.php plugins["#modulename#"]->ver etc
+      * Perhaps XML would be better for having this info
+   * (deboutv) In my plugin manager, I have chosen to provide Mantis plugin in pkg format. This file is the result of a zip and a serialize of an array => gzcompress( serialize( array ), 9 ); The array contains the following fields:
+<code=PHP>
+$t_pkg['plugin'] = 'string'; // The plugin name
+$t_pkg['check'] = array(); // The array of requirements to be checked, eg: array( 'mantis' => array( 'min' => '1.0.5' ),
+                           //    'php' => array( 'min' => '4.0.0' ), 'plugins' => array( 'pluginmanager' => array( 'min' => '0.1.2' ) ) );
+$t_pkg['files'] = array(); // The files of the plugin (base64 encoded), eg: array( 'plugins/bbcode/core.php' => base64_string, ... )
+$t_pkg['remove'] = array(); // The list of files to remove.
+$t_pkg['info'] = array(); // The plugin info (version, name, id...)
+$t_pkg['info_pm'] = array(); // The plugin manager info
+</code>
+   * (deboutv) Hacking Mantis with a plugin. We need to think about the security of the Mantis application and its data. Allowing plugins is dangerous because of the content of the plugin (it could pretend to be a BBCode interpreter but in reality it could be a BBCode interpreter and a spy). With a plugin (ie: code of third parties), you can read/write the SQL database, grant priviledges to the users...
+   * (DGtlRift) There should also be a description of how plugins themselves should generate events.  This would allow additional optional functionality //between// plugins.  EI: plugin ''doesSomething'' generates event ''pe_doesSomething_special'' so that plugin ''somethingElse'' which doesn't require plugin ''doesSomething'', can optionally do something additional if that plugin is installed.
+   * (DGtlRift) Re: Distribution.
+      * The most simple way is to just have a list of tar.gz compressed archives of each plugin.  The admin would have to download them and uncompress them into the plugins directory. After that, they would be available for activation from with Admin for Managing plugins.
+      * The next option would be to offer the ability to install via the admin interface, where Mantis would check against a web list of available plugins and download (to the server) and install the plugin (requiring Mantis to have write privileges) to the plugins directory.  There are some serious security issues involved with this method, but it gives one unified interface for the admin.
+      * Another option is to have all the plgins in RPM form - which would automate installation for the sysadmin.
+   * (DGtlRift) Should the plugins be globally "turned on" by the Mantis Admin or should each project have the ability to enable/disable installed plugins?
 ==== First implementation ====