On 7-Jun-09, at 8:39 AM, John Tamplin wrote: > Yes, the very thing you want for real apps (async so you can drop > back to the event loop and let the browser respond while waiting on > IO) is the very thing you can't have for OOPHM, since you have to be > able to block the executing code in the browser until you get the > response from the server (since you are emulating synchronous calls > from JS->Java).
Yeah... The XPCOM scripted component prototype I have uses the OPEN_BLOCKING (see https://developer.mozilla.org/en/NsITransport) flag when opening up the streams to the OOPHM server to ensure that all cross-channel calls are correctly synchronous. During the code, the JS IP is bouncing around within the JS component, never yielding to the page script itself. Since the browser is executing chrome-level code, the user doesn't see a slow script warning either, just a frozen browser (as expected). I don't forsee ever being able to do something like OOPHM without having some sort of per-browser native plugin or script component due to this single issue. At least on FF, those components could possibly be written in JS to minimize platform porting concerns. Even if browsers supported native JS continuations, you'd still have to ensure that no other JS was able to run (in-flight XMLHTTPRequest, event handlers, etc). Matt. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
