Lothar and Mike have made some good points. Here are a couple of perhaps more obscure ones:
- The RPC wire format is about as compact as you can get because it's _not_ self-describing. This is a plus if you're shuffling lots of data around, but I don't know how to define "lots" for you. - There's plans to make the deserialization of RPC responses "asynchronous" so you don't tie up the browser thread reading large responses. You'd have to do the same thing manually with large JSON responses. - Using RPC is a nice way of abstracting the transmission details and saying "I don't care" about the wire format of your requests and responses. This means client-server interface management is reduced to managing the evolution of a Java interface, rather than worrying about whether or not the client and server are in sync. It also means that some mismatches between client and server can be caught by the compiler. - It _might_ be easier to re-use an RPC server-side than a JSON server-side because the RPC-specific details are already pretty well isolated from the business logic. Ian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
