Changes

Stage 1 2 is completed - see the main [[Tamarin:ScreamingMonkey]] page for details. We currently havea prototype an engine implemented that works (with some limitations) inside Internet Explorer andincludes the self-hosting esc compiler. We are in the planning stagesfor Stage 23.

== Stage 2 3 ==

Work in stage 2 3 will be prioritized towards letting people experiment with focus on the things that do not work in the current implementation, and as such, it will try to follow the 80-20 rule - hopethat we can capture 80% also on taking advantage of the use cases new facilities in 20% of Tamarin (eg, the worktracing engine, ESC improvements, etc). Simple webpages will work, but lots The tasks below have been listed in rough order of complex things will notpriority.

However, this is not to say we want to take short-cuts. tests are included,as well as other tasks * Documentation: improve the wiki and the "welcome" page that may impact comes with the overall architecturebinary release. Publicize release and act on feedback.

* Implementations of AXScript interfaces as described belowEvents; currently events work only via AttachEventHandler. Assigning events to the Window object does not work like it does in JScript.* Integration into a build system so See the ActiveScript binary comments in axscript/test/events.html for more information, but MarkH is createdout of ideas.* Developer documentation and some initial unit tests Anyone have a contact at MS we could leverage?

* Better understanding of the tamarin "globals" concept and integration with the same AX concept. Understanding "per-engine" and "per-process" (and "per-thread!" considerations. Ensure re-initialization of the engine works (in theory, if not in practice)Implement eval {{bug|413434}}

* Events; need to setup connection point handlers Understanding "per-engine" and dispatch events to the correct handler. Need to integrate various ways to handle events, including enumerating the global namespace to find 'window_onload"per-process" (and "per-thread!")'style eventsconsiderations and ensure things are cleaned up correctly. Almost certainly will require using ITypeInfo for metadata about the event Test DLL can be unloaded and/or enumerating the events on an objectreloaded.

* Engine "state" management:** "queue" up compiled code until state says Use ESC to run; keep "persistent" compile the engine implementation, so we can move the implementation of the JS2 engine to JS2 (SCRIPTTEXT_ISPERSISTENTinstead of the ActionScript it is now) blocks around so , not rely on the engine can "reset"external ActionScript compiler, including 'source context' for exceptions.** consider future event handling "connection" state requirement.** respond to asynchronous "stop" requestsand be fully self-hosting from the tamarin tree.

* Better exception integration. Need column number, and need Implement the "Clone" method as a way to remember the source performance optimization (it should prevent all script code we are compiling (see re-executing when a new window is created) [http://msdn2.microsoft.com/en-us/library/dwy967hzt4f5c129.aspx IActiveScriptErrorIActiveScript::GetSourceLineText]) Clone(see "state management" above). Sane handling of syntax errors etc].

* Possibly modify Tamarin, Investigate and/or add a new 'extension' to better expose the implement correct handling for "globalbinary" semantics to js2(ie, with the aim an array of keeping VT_UI1) data (ie, returned as much of the implementation as possible to be self-hosting.string or array?)

* Integration with Moz build environmentBetter exception integration. Need column number, and need a way to remember the source code we are compiling (see [http://msdn2.microsoft.com/en-us/library/dwy967hz.aspx IActiveScriptError::GetSourceLineText])

* Implementation Integration with Moz build environment, including possible signing of the other ActiveScript 'Parse' functionsbinary.

* Documentation: update Wiki with "getting started" docs Many minor cleanups and other fluff. * Basic test suite: implement using Python and pywin32; the latter has intrinsic support for these interfaces. * Process for making binary releases for beta testing (but *not* via an installer - just a binary they can unzip and register optimizations, as identified by hand)** who makes binaries? signing considerations.** "packaging" of '// XXX' comments in the abc files needed by the compiler so we have a self-contained DLL? * Better VARIANT support, including arrayscode.

* IProvideMultipleClassInfo * Implementation of GetScriptDispatchsniffing for events () although its not clear if this is necessary - this means implementing IDispatch so external callers can call functions etc defined in the script, see variables, and other goodness. * Ability for an engine to be "cloned" - [http://msdn2.microsoft.com/en-us/library/t4f5c129.aspx IActiveScript::Clone(discussions re events)]. Presumably this is just an optimization... * Ability for scripts to be interrupted - [http://msdn2.microsoft.com/en-us/library/ecadx4td.aspx IActiveScript::InterruptScriptThread]