It's kind of a hackneyed image: the magician yanks the tablecloth out from under the place settings for an elegant meal, leaving the wine glasses and candlesticks in their places, unperturbed. A neat trick, but even better would be to replace the tablecloth with a new one, all without touching the candelabra or the crystal goblets.
I'm not usually given to hyperbole, but with our latest Legals snapshot, PR3, we are nearing the end of a process that feels a lot like replacing the tablecloth: LZPIX still runs, has continued to run, against an OpenLaszlo source base that has seen extensive renovation, refactoring, and rehabilitation. Over the last couple of milestones, we have:
- Merged the custom DHTML runtime used in our earlier prototypes into the original runtime, and refactored it all to yield two clean kernels (SWF7-8 and DHTML) and a target-agnostic OpenLaszlo Runtime;
- Built out the two kernels to be nearly feature-complete and to match the draft Kernel API proposal;
- Added compiler support for several draft elements of the in-process ECMAScript Release 4 specification;
- Converted all of the OpenLaszlo Runtime to use the proposed ECMA-4 class declaration syntax, and in the process modified them all to directly work with the new OpenLaszlo class model;
- Resolved a large number of compiler warnings that would turn into fatal errors in DHTML;
- Made great strides designing a flexible mechanism for selecting vector or raster graphics assets based on runtime;
- Fixed a large number of difficult browser-specific bugs, including leaks, performance issues, and media/data loader quirks; and
- Further demonstrated the capabilities of the Kernel API by prototyping an SVG kernel in just a few days.
It turns out the tablecloth trick requires low friction and high inertia. The tablecloth slides more easily from under heavier objects with smaller contact area. Software doesn't have inertia or friction per se, but perhaps metaphorically we can think of test methodology as the equivalent: stable change is easier when you are able to quickly detect adverse consequences of a proposed modification. Consequently we've been steadily investing in unit testing infrastructure and unit test coverage, without which we may not have been able to refactor the runtime so quickly. As well, the Laszlo QA folks working on OpenLaszlo have done a wonderful job keeping our standards up with respect to LZPIX performance and functionality. There have been a few regressions, and we need better performance metrics, but having a solid test plan for LZPIX has really helped us maintain high standards.
All in all, we're solidly on the road to our upcoming Beta release. Toward that end, the next challenge is to bring up the OpenLaszlo widget toolkit in DHTML, a process that will certainly shake out a substantial number of remaining issues. Stay tuned!
