Revised Plugin Architecture (split from Front End Editing)

Quote from: infoclipper at Aug 14, 2005, 12:16 AM

Two thoughts on my initial reading (keeping in mind I have been up for three straight days now working on the new manager w/ no sleep):
...
2.  If you have two plugins with a function named init(), which is what it looks like you are suggesting, the entire system breaks.  Hence the classes:  six plugins can use the same function names and no one cares.  In fact, this is actually DESIRED since you can create a common API.  $plugin->getEvents(), for instance, can return the events the plugin wants to listen to regardless of the type of plugin.  Or $plugin->doInstall(); can always run the install for the plugin, creating any needed tables, etc.  Standardization and predictability is key.

As for filesystem:  actually, it would be exceedingly more difficult to be more inefficient than the system currently is, from memory storage to caching to a lot of the DB structure.

And execution order *definitely* needs to be controllable by the programmer. 

Can we gain the best of both worlds, perhaps? With a DB-based plugin system, you get all the GUI-goodness when appropriate. However, with a new caching system, it could actually compile all the related events into a single cache file. For example, if you had five plugins that listen to some event, it could compile all five into a single cache file that gets executed from a single include call vs. five includes.

From the management side, I’d think that’s just another level of security that needs to be added to Manager Roles (can edit plugin config, can edit plugin execution order).

No system of any complexity should remove that control from the ones writing the code.  I have at least a dozen ideas for plugins that execution order is a necessity; it’s not even possible to write them without that control.  Heck, even the most simplistic blogging software has these controls built into the API; no way we are going to ever be taken seriously while stripping such control from the programmers--  execution order is even the first thing they teach in freshman level programming courses!

Here’s where the beauty of a file-system based plugin architecture shines. And it’s very similar to what programs like Photoshop do anyway, but that’s another argument entirely. Drop it here and it just automagically works. The likelihood of an average user EVER needing to alter a plugin execution order is remote at best. However, the ability to backup a site via the database is pretty compelling too. I think vBulletin does a lot of their managment stuff via the Database for this reason.

However, if we come up with a great installer/packager AND a killer caching system AND a more robust security/access/roles model for manager functions for the plugins/modules/etc., then the argument for the file system based approach is not quite as weighty in my book and I lean back towards the pure-manager based approach.

But regardless, I like both solutions and think either way will be a definite improvement over what we’ve got today, no questions asked.

The way I understand the plugins to work right now is that all the plugins load and are fired, even if there is no event being acted upon by plugins. Similarly, all the events fire if no plugins are listening to them. After talkign to Travis about this, the following got brought up as a possible solution to balance that out:

1) Plugins are installed from within the manager.
2) Upload form uploads new ones as needed.
3) Manager scans all plugins in some specified folder and gives option to install new ones as needed.
4) On install, the plugin is queried and the events it listens to are registered in a DB table. I assume that it could also register config params in a (even the same?) table as well, such as execution order.
5) Thus, to get all the events, the core just has to pull the records from the table (single query).

The plus:  events that have no plugins listening don’t have to fire
Another plus:  only the active plugins are loaded from the FS

Basically, by having a config table you get the ease of use of the DB. By placing them in classes on the filesystem you don’t have the memory consumption or the huge overhead of the eval() calls.

This then still leaves the question of combining the two techniques by introducing caching of all plugins that listen to the same event in a single file on the FS, so you get the reduced eval() overhead + potentially fewer includes on the FS.

Anyone that knows more about this stuff than me care to comment?

Quote from: rthrash at Aug 15, 2005, 01:55 PM

The way I understand the plugins to work right now is that all the plugins load and are fired, even if there is no event being acted upon by plugins. Similarly, all the events fire if no plugins are listening to them. After talkign to Travis about this, the following got brought up as a possible solution to balance that out:

Plugins are cached in the same way snippets and chunks are cached. All plugins are stored inside the $modx->plugins array. Plugins are only invoked or triggered only it the event they are listening to is invoked. If an event is triggered and their is no plugin listening to that event then the control is immediately returned to the parser. The system is designed to allow plugins or custom events to be registered and invoked at runtime.