Details
-
New Feature
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
Falcon should support a clean plugin architecture which should enable developers to extend or modify the compiler's behavior in an easy manner.
A set of hooks ought to be defined that make sense to plug into. Suggestions for these hooks are:
- An AST postprocessing hook which enables a plugin to modify the AST
- An emitter postprocessing hook which enables a plugin to modify the emitter's output
Perhaps the emitters ought to be seen as a form of plugin as well? ABC output and JS output could then simply be configured as plugins. (This way its even possible to output SWF and JS output in one run)
Besides defining interfaces for these hooks there ought to be a simple discovery mechanism for the compiler to locate plugins.
Simplest solution would be a specific directory (or directories) that the compiler watches. Any jar added to such a directory will be scanned for implementations of the known plugin interfaces and registered with the compiler.
For more verbose configuration probably an XML dialect will be needed. In this XML the plugin locations might be defined, but also things like enabling a plugin to run only in debug or release mode could be defined here. The location of the plugin could even be a URL, that way plugins could, for example, be downloaded directly from a Maven repository. (Flexmojos could play an interesting role here)
This ticket is meant to start a discussion, so please feel free to throw in your 2 cents. Designing this plugin architecture as cleanly as possible is very important. So please discuss.