Sounds good. Is the gwt-rpc format described, so I could write a non-gwt app (say, a mac desktop gadget) that hits my server using the same api as the gwt-rpc browser app? Note, I don't actually care right now what the format is, just that the protocol is described, and is easy to impl in a non-gwt-rpc-browser app (like it is with json ;-)
On Oct 29, 10:30 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
