Nucleus 5: Plugin API 2.0

For Nucleus 5, we need to establish an easier way to install and update plugins. A core installer, connected to a central repository, was discussed once and the idea needs to be developed.

Trex proposed a new plugin API, the Nucleus Plugin API version 2, which is described below:

“Plugins for this API would inherit from NucleusPlugin2, which is inherited from NucleusPlugin, thus making a clear distinction between 'old'-style plugins and new style plugins. The API 2 plugins would be packaged in a .tar file (and give it the extensions 'tnp' to make it clear it is a nucleus plugin, although that's only optional). To install an API 2 plugin, a user would have to upload the tnp-file to his 'uploaded-plugins'-folder and install the plugin. Nucleus would then extract the tar, copy all files to the right directories, create the options, tables etc.

The info on how to install the plugin wouldn't be in the plugin, itself, anymore. The install() and uninstall()-methods) and everything would be described in a separate file (plugin.meta or something like that) This is why it should be a new API. This has some advantages:

• The (un)installation of a plugin has nothing to do with the actual use of the plugin; so, separating this is a good thing, I think. Look at most software; for example, extensions in firefox: they all have a separate install mechanism, install.rdf, I think.
• Most (99%?) plugins do two things in their install(): create options and create tables. Currently, Nucleus only knows what options are created by a plugin, but it has no control over the tables that are created during install (or modified), if it is a bad plugin that modifies core-tables). When we create a nice syntax for plugins to let them describe the options they need and the tables they need with the different columns, this could be entirely handled by Nucleus.
• Also upgrading would become easier; a user uploads a new tnp file and choses 'upgrade'. Nucleus reads the meta-file, checks if all the required options are there and are ok, checks the tables and creates/updates them, if necessary.
• Also uninstall will become easier: since the uninstall is handled completely by Nucleus and Nucleus knows which options/tables belong to the plugin (and are only used by that plugin). Nucleus can ask the user if they want to keep the related data.
• Plugin dependancy will also be defined in this file.
• Of course, there should be a possibility for plugins to execute some code during (un)install, but this should be discouraged.

The plugin api 2 will also use a new SQL table-function. Currently there are plugins that name their tables 'nucleus_plug_mytable' and 'nucleus_plugin_mytable'. This is not very good, imho. The new function would simply accept a name, describing what the plugin saves: for example, the foobar-plugins saves 'foos', then we would use: sqltable2(“foo”) which would result in table name “nucleus_plugin_foobar_foo”.

Other problems which should be solved with this new API (by somehow forcing plugin authors to do so) are:

• standard methods to translate a plugin should be handled, somehow, by the core.
• standard methods to skin/template plugin's output should also handled by the core.
• As discussed by Rakaz, it should be possible for plugins to interact more with the admin area. These problems were already mentioned earlier, but never got solved. By example, it would be nice to have a more 'wizzard'-style-publishing method with different steps. From every step it should be possible to choose 'finish' and it should also be possible to skip steps (by example the extended body). Plugins would be able to add extra steps. There would also be steps after the item was published, for example, pinging different sites.

• Also, adding extra pages to Nucleus is an often requested feature; so, by creating a design which makes it possible for plugins to hook at a lot of places (not only by using events), this would be possible. Such changes should be well thought out to make them as flexible as possible.”

• Installing a TNP file (see Nucleus Plugin API 2) could also be done by specifying a URL to the TNP file, skipping the “upload TNP file to uploaded_plugins” step. Naturally, we'll need to be able to prove that the install-plugin is 100% secure in this case [dekarma]
• As Boron will have a brand new architecture, inheriting from NucleusPlugin doesn't make much sense. Old plugins will probably no longer be supported anyway. [dekarma]
• Perhaps instead of tnp, something like np.tar? That way we don't break the .tar extension for Windows archive utilities to open the file. And support for np.tar.gz for gzipped files would be good too.

I think it would be better if plugins were just a bunch of classes, implementing some various interfaces (the one they need) to hook into the core plus a configuration-file (xml?) to install and update plugins. This is a bit similar to Plugins for jEdit. Those plugins, also, are just classes (and one PluginClass to 'start' the class, but that's because jEdit is a rich-client app and a bunch of xml-configuration files to glue everything together.

These are part of the Nucleus 5 plans. Read more about the project.