Stage 2 is completed - see the main Tamarin:ScreamingMonkey page for details. We currently have an engine that works (with some limitations) inside Internet Explorer and includes the self-hosting esc compiler. We are in the planning stages for Stage 3.
Work in stage 3 will focus on the things that do not work in the current implementation, and also on taking advantage of new facilities in Tamarin (eg, the tracing engine, ESC improvements, etc). The tasks below have been listed in rough order of priority.
- Documentation: improve the wiki and the "welcome" page that comes with the binary release. Publicize release and act on feedback.
- Better understanding of the tamarin "globals" concept and integration with the same AX concept bug 417342
- Events; currently events work only via AttachEventHandler. Assigning events to the Window object does not work like it does in JScript. See the comments in axscript/test/events.html for more information, but MarkH is out of ideas. Anyone have a contact at MS we could leverage?
- Move to tamarin tracing once ESC works there.
- Implement eval bug 413434
- Understanding "per-engine" and "per-process" (and "per-thread!") considerations and ensure things are cleaned up correctly. Test DLL can be unloaded and reloaded.
- Use ESC to compile the engine implementation, so we can move the implementation of the JS2 engine to JS2 (instead of the ActionScript it is now), not rely on the external ActionScript compiler, and be fully self-hosting from the tamarin tree.
- Implement the "Clone" method as a performance optimization (it should prevent all script code re-executing when a new window is created) IActiveScript::Clone().
- Investigate and implement correct handling for "binary" (ie, an array of VT_UI1) data (ie, returned as string or array?)
- Better exception integration. Need column number, and need a way to remember the source code we are compiling (see IActiveScriptError::GetSourceLineText)
- Integration with Moz build environment, including possible signing of binary.
- Many minor cleanups and optimizations, as identified by '// XXX' comments in the code.
The following tasks have been identified, but they have not been incorporated into planning. We expect the following tasks to be completed, but have not made any decisions about when.
- Consideration of the best way to "wrap" MSCOM (vtable based) interfaces so they can be called from our JS2 implementation. Example is the interface IE passes us (IActiveScriptSite). Current implementation has hand-written C++ wrappers, but this is only reasonable while the number of interfaces in question is small; which they currently are, but may not be if debugging support is added, or any other "ActiveX" related interfaces become desirable.
- AXScript "thread state" concepts (see IActiveScript::GetScriptThreadState)
- Locale considerations
- IProvideMultipleClassInfo sniffing for events (although its not clear if this is necessary - see other discussions re events)
Distant Future Tasks
These tasks will be done much further in the future, if at all. They are intentionally vague, as more details are expected as work progresses.
- Consolidates the work in the previous stages, making it suitable for a "real" release. Address automated testing, installation, integration with 'talkback', etc.
- Add debugging support by implementing the Active Script Debugger Interfaces. This step is optional, but would allow integration into the "Script Debuggers" from Microsoft.