While this thread may already have gone on too long in the wrong place, I do just have to say ... I don't use RPC at my shop. It is a bit forced, as the underlying RESTful plumbing of the web doesn't map tightly onto the RPC paradigm. GWT puts RPC style coding in reach, but I still prefer to opt for pure REST. I think we get better results. The evidence is anecdotal and qualitative, but weighty.
The provided JSON, DOM and HTTP modules, our own JSNI-based XML NativeDocument, and Restlet-GWT, among others, give plenty of ways to front end anything from Rails to Restlet to Lift with GWT applications. I am ... not enthused ... about masking the reality of HTTP even further with simulated continuations in RPC, when I think what's already there encourages non-optimal (albeit sort of easy) application design. My vote would be the opposite -- a renewed focus on the basics, to better document and encourage the simple and efficient RESTful practices GWT allows with many diverse server apps. These aren't hacky in the least -- and the Async patterns in GWT are quite lovely compared to writing XmlHttpRequest async code directly in JS. #gonegoogle because I needed a better REST client in the browser and GWT is one, - Rob On Aug 3, 2009, at 8:07 PM, John Patterson <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
