Sure, I'd love to take a look at it. I've got a basic version of globally-scoped, cross-domain code-splitting up and running that uses simple script-tags for the cross-domain load right now.
Re: <script> tag error reporting. In my investigations, this has been particularly bad and highly variable across browsers. I came away with three conclusions: 1. onload or onreadystatechange works across all browsers to detect a successful load, but it's moot because you can use JSONP callbacks to do this. 2. onerror works some of the time in some of the browsers. It fails on various combinations of resolve errors, error status codes and other failure conditions. For all browsers (except Opera) that don't support it directly, It can be emulated with onreadystatechange/onload and lack of a JSONP callback. 3. Opera can't detect that a script failed to load in any way that I've found: none of window.onerror, script.onerror, script.onreadystatechange will fire when the script fails to load. Matt. On 30-Nov-09, at 1:27 PM, Lex Spoon wrote: > Hey, Matt, > > I agree with your analysis about the code-splitting issues. > > I've worked out a preliminary patch to do var renaming, but I haven't > shared it yet because it's in a pretty early state. I could share it > if you or someone is eager enough to see it that you're willing to > hack some code to get to use it. > > To really get it polished up into a committable state, the main issue > will be figuring out when to enable the rewrites. Whether to enable > it or not depends on the choice of linker. > > For the off-domain loading, I was thinking to look into a JSONP-like > downloader. That, too, is something that should only optionally be > enabled, because it has worse download failure reporting. Thus, again > the hardest part will be figuring out when to enable it. > > Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors