Hi! I completely agree with your comparison between GWT-RPC and SOAP XML, but it is just too convenient for me to reply to your post with the non-conflicting argument for JSON web services as a viable middle ground:
On Tue, Jan 13, 2009 at 2:42 PM, gregor <[email protected]> wrote: > In practice this is almost certainly an unfavourable option because > SOAP is a bloated over complicated XML based data exchange mechanism > by comparison to REST, JSON, That's still a web service in my book. That's what we use in fact (REST with JSON), with SSL and basic authentication. The project is still in the pilot phase, but we are getting there. Client side performance does not seem to be an issue so far with our expected dataset sizes: modern cell phones seem to handle it fine. > and particularly to GWT RPC. GWT-RPC is probably the most efficient on the wire and in the client, true. On the upside we expose (develop, secure and load test) one interface for both human and machine consumption, and can use the server-side platform of our choice (currently Jersey) independently from client development (currently GWT). > In other words your application will run many times slower, Let them use Chrome ;-) Seriously, I very much like the idea of off-loading application state, data manipulation and GUI rendering all to the clients, leaving me with a stateless, cacheable, data-only server (plus the static download of the GWT client). Client hardware specifications are often within the order of magnitude of server nodes anyway (they may even exceed them in our case...) > and you will have > to write hundreds of lines of code to create, serialize and deserialize large > XML strings. Not as nice as GWT-RPC sure, but JSON and third party stuff like Restlet-GWT can help with that. (For the pilot we just roll our own to better understand what is going on.) I keep bragging about this approach here to invoke constructive criticism, so please discuss. I know some of our cornerstone design conditions differ from the general case, so I'll list them here: - We need to publish web services functionally equivalent to the web GUIs anyway - Single-page, desktop-like applications - No need for SEO, no need to spy on users^W^W^Wcollect usage statistics - Applications may need to scale (both up to millions of users, and down to a few on restricted hardware.) I think enough of these conditions hold for Marvin's case for him to consider this architecture. Gabor Szokoli --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
