On 3 Aug 2009, at 22:22, Bruce Johnson wrote:
> 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. I can see how the current system makes it more obvious that this is not a normal method call. But this is exactly the same scenario as a normal Java blocking io call. When I use java.util.URLConnection for example I am fully aware that I need to think about timeouts, connection errors and updating the UI. The checked exception reminds me of those outcomes. > 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. It would be just as easy to not show a busy indicator in the current system. In fact I would argue that the additional clutter makes it harder to see the "real code" from the boiler plate, making it easier to overlook places where you have missed it. The argument "it makes you think more" can't really be used to justify jumping through hoops and forcing the users to maintain the parallel Async interfaces. It is very reminiscent of EJB clutter. As a new user to GWT, I am very impressed by the rest of the API but this parallel Async interface is the part the cries out hack! If continuations are able to be used by the compiler to rid the system of Async interfaces the GWT world would be a better place. John --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
