Although it feels less convenient, the async nature of RPC is actually valuable for usability. It forces you to think about what to do in the application UI while a potentially long-running activity is taking place. When you consider that a network round-trip combined with time spent on the server could easily take multiple seconds on average, that's an awful long time to have the UI thread blocked doing nothing. If it were possible to write blocking (or even, seemingly blocking) calls, it would be too tempting to not think about the user experience -- in other words, in most apps the UI would simply hang -- and it's probably prescibing a horrible user experience.
On Mon, Aug 3, 2009 at 6:57 AM, John Patterson <[email protected]>wrote: > > > On 3 Aug 2009, at 20:53, Miroslav Pokorny wrote: > > > > > The Async interface is necessary because one does not want to use sync > > (blocking) rpc calls back to the server. When using blocking calls the > > entire browser freezes which is especially bad give responses arenot > > instantwous. > > I was suggesting the use of continuations to _mimic_ blocking calls > but allow the thread to continue. Then from your Java code you would > not need to worry about passing in a callback to every service method. > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
