assuming you agreed with initial thoughts of reusing wp plugin management, very simplistically, the core plugin file (they would, of course, provide potentially many other routines and files to peform its functions) could look something like this:

<?php
/*
Plugin Name: Simple:Press Plugin XXX
Version: 1.0
Plugin URI: https://simple-press.com
Description: Fully featured but simple page-based forum plugin
Author: Andy Staines & Steve Klasen
Author URI: https://simple-press.com
WordPress Versions: 3.0 and above
SimplePress Versions: 5.0 and above
For full acknowledgements click on the copyright/version strip
at the bottom of forum pages
*/

# register plugin on activation with simple:press
register_activation_hook(__FILE__, 'sf_register_plugin');

# admin stuff
add_action('sf_plugin_admin_menu', 'sf_admin_menu');
add_action('sf_plugin_admin_scripts', 'sf_admin_scripts');

# front end stuff
add_action('sf_plugin_head', 'sf_header');
add_action('sf_plugin_forum_scripts', 'sf_forum_scripts');

?>

the first section registers the plugin with us…  we would do whatever we need to to keep track of it…

the admin stuff would be there for the plugin to add simple press admin menus and js…  they would provide the routines for when the action was fired…  we would need to provide the additional api routines for allowing them to actually add the menus, but thats a different discussion (do we create new major admin section called plugins and make them all subs under there?  or allow them to add to existing menus?  or both)

Now, just like wordpress, we would actually probably want to create a lot more actions we fire… basically, whenever we hook into wp, we might want to fire a corresponding action…  this would allow our stuff to run first before the plugins. plugins could always use the base action and just jack up the priority if needed…

so, this was just kind of a basic scheme…  and of course, if not admin menus or js, no hooks needed… but some will be needed somewhere, I would think…

and not really sure we need that activation registration… seems like we might want to know the registered plugins, but might not really be needed other than informational purposes…

thoughts?

Half of me would like to do our own thing – have our own plugin folder and activation code and 'include' plugin files which is – in reality – pretty straightforward.

The other half can see the sense of using the framework that already exists so I am not going to argue in favour either way. I think the only real benefit of our own plugin folder and routines is that we will not be asking users to have to activate multiple plugins when they set up SP but instead would be able to present them with a list in an admin 'plugins' panel. Not really a big deal but a genuine point in favour.

On the question of what we should pre-supply as plugins I would strongly recommend as many as possible. It would be a very neat way of allowing users to have a very lightweight system – more in direct competition to bbPress – whilst allowing them to boost up the functionality as preferred. Doing this would also ensure that the plugin architecture is capable for others to create components and not restricted to 'easy' stuff.

There is one item in developing functionality as a plugin that it will be very important, and possibly tricky to implement but that is again at the core of getting it right. That is tying in display/presentation aspects of a plugin with our templating plans. These are not yet known of course but it might be that plugins have to follow some very strict rules in regards to providing that interface layer.

This should be good!

took a look last night at all the code WP uses for plugins page, activation, etc etc and its a pretty sizeable chunk…  and a lot of the code is because of the options they give folks to filter, add, remove stuff from the login page, notifications, etc..

now we wouldnt necessarily need all that, but stil would be nice to have our own plugins admin page, just worried about re-inventing the wheel…

and agree on wanting to package up a bunch of our stuff as plugins…  I can see it already: 

http://plugins.simple-press.com

but all gets back to your run rules for 5.0…  need to put together a task ordering list so we can sequence through all the 5.0 stuff…

if we DID do our own plugin folder (and again – I swing both ways on this.. er – can  I say that!?) then I dont think we would need any extra stuff like WP has. Just check it on or off and if it's on we include the main file and the plugin code has to do the rest… Wouldn't it be that simple? Or should I say Shouldn't it be that simple?

maybe.  driving in to work today was getting excited about doing our own thing – typically what we do!  

Still need to code up (or borrow from WP) something for parsing the plugin files and extracting the plugin info… then display it and allow for activation and deactivation…

but if we ignore stuff like the different display options (active, deactivate, recent, etc) gets easier… and dont provide a bunch of filters and what not for total customization of how the plugins rows look, gets easier again…

so yeah, thinking now to do our own thing, but start small and simple… if we want to add a bunch of hooks and filters later for the plugin display, we can do so…

so will start gearing my thinking towards that…  AND depending on how it plays on your task list order/dependency, could start mocking up some stuff – secondary to making sure 4.3 is ready of course…

I think that would be all we needed. Off or on. Just like turning on modules in Gallery2 or Invision Forum.

Although one thing we have not mentioned is the fact that an SP plugin – no matter where you activate it – is quite likely to need an admin panel…. That's going to take some thinking about.

already have in mind an interface like the current wp admin menu stuff…  basically, a way to add a top level sp menu (ie forum, options, components, etc) or add a sub level menu to one of the existing…  also think will create a new plugins top level menu for the plugin management…

And… something else to consider – sorry, this is just as I think of them! Permissions.

Converting a current SP component to a plugin that might have a permission defined – or – a new plugin component that requires a permission.

A plugin would need to be able to create a new permission and remove one if the plugin were turned off.

oh yeah, but you are down in the weeds!

we wil have to add a whole bunch of new methods and what not (hooks, filters, etc) to support plugins…

First step (for me) is getting plugins to be recognized, then activated and deactivated, then loaded and then have an admin panel of its own (or perhaps added to existing one)…

after that, time to start having the plugin actually do something… thats when things like permissions, displaying stuff, available hooks/filters, etc will come into play…  suspect a bunch more we havent thought of…  then timet o start converting existing capabilities to plugins and see whats needed…

the one that worries me the most is the display stuff…  but if we output as we go, and provide filters for changing up the content, should make that easier and more straight forward than today would be…