2009/6/7 John Tamplin <j...@google.com>: > On Sun, Jun 7, 2009 at 9:46 AM, Thomas Broyer <t.bro...@gmail.com> wrote: >> >> On 7 juin, 02:24, Mark Renouf <mark.ren...@gmail.com> wrote: >> > If the WebSocket >> > standard ever materializes, it could be even better (and standards >> > based), and act as a last-resort fallback on all platforms. >> >> WebSocket is all about async communications which is a show-stopper >> for OOPHM. When I prototyped theOOPHM support for Adobe AIR in GWT-in- >> the-AIR, I first thought about using the network classes available in >> that environment, unfortunately they all are async too, so the only >> solution I found is using the AIR debugger to stop the execution or >> the AIR runtime (break point) and then read and write variables as an >> alternative to passing values on the wire. > > 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).
Can't you emulate sync calls with async calls in js? Locking would be best but can't you always retract to busy looping? -- Best Regards, Piotr Jaroszyński --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
