Plugin Architecture: Hooks and Callbacks

[eluser]Unknown[/eluser]
Having recently joined CI, I brought up a topic in the Introduce Yourself area that is better served here...

The Need

PROBLEM: When designing an application, one doesn't know how the application will evolve, what features it will grow into, how many ways it will present itself, etc. How can one not only mitigate risk, but also enhance the application's ability to be successful given the lack of foresight?

SOLUTION: Design for extensibility. One technique is to carefully consider the core logic and write it, placing hooks at those places where one might either extend or replace something.

For any application that is being developed, careful consideration will reveal the core logic for that application. The core logic is a small kernel of code in which the fundamental code has hooks that implement initially-conceived functionality. Callbacks are registered for these hooks for the first version of the application.

Invariably, during the development process, those functions need to be expanded or replaced. Each of the defined callback functions themselves can define hooks themselves. This allows core, 3rd-party, and modifications to 3rd-party extensibility to take place since each can define hooks and register callbacks.

What Others are Doing

There are a number of frameworks that do this kind of thing:

* MediaWiki Hooks
* WordPress Plugin Hooks
* SquirrelMail Plugins
* Cacti Plugins
* Smarty Plugins
* PHPClasses: PHP Callback

In designing a plugin architecture, there are a number of things to consider:

* hook/callback architecture - deciding on how it works.
* static plugins - plugins live on the server as part of core/generally-available plugin sets available to all users.
* user plugins - plugins that are available to only specific users.
* plugin loading - are plugins loaded: always, never, or only when needed? Can they be unloaded?
* plugin installation - is there an API for plugin installation? This can be used by system administrators or provide functionality so that users can upload their own plugins.[/b]
* web services - are plugins exposed as web services APIs? Are these authenticated? This allows the functionality of the application to be not limited to just one website... it or parts of it can be embedded in other websites.

Why is it Worth Doing?

A Plugin Architecture, implemented as Hooks with registered Callbacks, enables an application developer to mitigate risk due to unforeseen features, allows the writing of cleaner code, makes 3rd-party plugin development an automatic opportunity, makes documentation more compartmental, reduces QE costs because the code is significantly more modular, makes it easier to have a larger team of developers since they're able to work independently, and makes Web Services APIs easier to implement and maintain.

So, since many of the applications we build are built with a plugin architecture, and since we're now looking to add CodeIgniter to our development framework for many of the same reasons, I'm wondering:

* What would be involved in modifying CI's hook code to become a separate class that can serve not only CI's needs, but also allow developers to use it for their own code?
* What, if anything, has been done already?
* How do we work with CI's developers on this? If this is something that has not yet been done, since we're going to do something, we might as well help out the CI community.

Happy Holidays!