Niel, I've tried to bootstrap the framework once, but I've reduced it to the minimum required to support MXML (so no visual components, collections etc), only bindings + some other stuff I wasn't able to remove. It would be all in all about 30 classes. So, if you are interested, I could give it a try, but there's one important thing about it: current Flex compiler expects the AS3 classes to be in place, either as sources, or in the framework.swc (probably, it would be able to take them from another swc - that's something I didn't try), but if they aren't found, it'll replace them with the ones it "knows" to exist. So it would be quite difficult to compile in parallel and see if the results match.
Another thing: what I could understand from Michael and Alex is that the way the code used to be generated is going to change - and we don't know in what way. Those classes depend on the generated code to work properly (they are usually instantiated from the generated code). Also, so far I could understand, no one is planning serious changes until Adobe releases the last stable version - until then it's kind of pointless to try to make changes, because we have a good chance to get out of sync. Yet on the other hand, the new compiler is going to compile MXML directly (why is that is another question... but I'm not asking it). And this later fact is putting anyone who would think about circumventing AS3 generated behind MXML into a very problematic position, as they would also need to generate the same code from MXML... I actually have difficult times understanding the ways the new compiler is going to be used - will it replace authoring_asc.jar for Flash CS? If so, I'm kind of lost, because there's a lot of technology built already on top of it, especially technology that involves code generation, use of AS3 compiled libraries and so on. So, how would Adobe continue to plan their own development in sync with Apache? I'm not saying it's impossible, but sounds strange... Best. Oleg
