Hi, thanks for reviewing. I'll wait until next weekend for other ideas and discussion.

The list so far:

1. Auto-calling plugin actions for build-in tasks/actions, it means we

should add (in index.php) code for automatic calling of actions e.g. 'mail-compose-before', 'mail-compose-after', 'mail-sendmail-before', etc. and probably also 'mail-before', 'mail-after', etc.

yes - sure. btw. I like the style "mail-compose-before" (or "user-login-after" as in my example) It's pretty clearer than my definition. I'll patch the existing code where I need it right now. Maybe we could team up to implement it everywhere, or could implement it module-by-module. We should have a list where actions should be called. I do not have the time to do this alone.

2. Possibility to use own tasks/actions (I mean

/?_task=settings&_action=myaction or /?_task=mytask)

such as a calendar-plugin ;-) lovely. Would be great - but somewhat out of scope I think. Shouldn't we better concentrate on the core plugin-arch and extend it later? But we have to talk about how to implement this later.

3. Javascript part - for javascript functions/actions (in similar

fasion) including point above.

again. Out of scope for my purpose. How can we extend it later to support this?

4. Possibility to add UI part from plugin without skins modification.

It's "must have", but I think, we can live without that for now.

same. We do not have any of these options right now so let's do the core.

5. Actions priority - if we have few plugins for the same action which

should be executed first? 6. Config option(s) for enabling/disabling plugin parts. Let's say we have a plugin with few features, but we need only one. Ok, we can have separate configuration for each plugin, but maybe something global? Let's say using regexp. It may be used for temporary disabling whole plugins without removing files from plugins/ dir. E.g. $rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.*

plugin3::settings.*';

Yes, agree. I thought about it but someone on the list denied the use of configuration. But I think this is a must-have. $rcmail_config['disabled_plugins'] = 'plugin2 plugin3::mail-compose.* plugin3::settings.*'; could be a problem because a plugin could possibly rely on some actions - which could be turned off (2nd and 3rd example). What about: $rcmail_config['enabled_plugins'] = array( 'plugin1', 'plugin2' ); If a plugin has parts which could be turned off and on it should have it's own configuration. This is IMHO the plugin part.

...

Just to make sure. The plugin system we're talking about here doesnt

just

...

allow actions, but also small hooks everywhere throughout the

code/templates?

Yes for me. I think templates engine should call plugin actions before/after each template object (objects, but also e.g. buttons and every template tag with specified name) and return content from those actions.

Hi, A.L.E.C., thanks for joining us in design phase ;-) Everywhere in the code - yes. This should be a milestone in future. Everywhere in the template - I don't know much about your templating. How/where do we have to implement it?

Just an idea: Does it make sence to split things up? This 'fackend-plugin' project for server side actions A new "frontend-plugin' project for client side things like JS, Html, Ajax-Client, ... Both should share the ./plugins directory so that a plugin can work with both. As I do not have any good insight of RC-Templating this could be a bad idea anyway. Dont know.

Waiting for futher comments ;-) Thank you.