On 4 Aug 2009, at 09:26, Rob Heittman wrote: > 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 protocol you use is a related but separate topic to the flow of control. When using RPC (XML-RPC and SOAP) in the past I found it worked great and saved a lot of complicated URL manipulation. With enough "plumbing" you end up with your own RPC system, no? > 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. Horses for courses. > 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. REST frameworks also masks the reality of HTTP. In fact that is one of the benefits touted by Restlet. "Easy" is not the main benefit. It is less error prone and easier to maintain. It moves some of the complexity from each client into the framework. I have already seen people on the lists talking about problems keeping the remote and asnyc interfaces. There is even an issue asking for the Eclipse plugin to automatically track the two of them. That is a sure sign that something is questionable about the API > 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. That isn't really "opposite" - just a different area of functionality. Both could exist. Also, good documentation would be needed to say "this remote call could take a long time". But that is not a hard concept to grasp. > 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. I bet you were into the lovely EJB artifacts too? Ha ha this is strangely reminiscent. Again, I don't think that making the developer more mindful is a good enough reason to make the API more complicated and client code harder to maintain. But if there are technical reasons why continuations generated by the compiler in JavaScript would not work.... well that is a different story! John --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
