> Also, will this be supported on methods themselves? For instance, can > I mark a new method parameter as @Optional so that older clients don't > need to provide it? Conversely, could we remove a parameter from a > method and still support clients sending data with the old signature?
I could go either way on that. My thinking here was to just use the existing Java method override semantics. As long as the servlet has a method that will accept the parameters actually sent by the client, the request would proceed. The older methods wouldn't need to be in the RPC interfaces themselves, just (deprecated) methods on the servlet. > One more question... Is it possible to incorporate the idea of > "numbered" fields into this design? This would make it much easier to > interop with Thrift (and possibly protobuf), both of which use numeric > keys for versioning. We'd probably write some code to output GWTRPC- > compatible Thrift objects from our IDL, which means that we'd have > numeric keys already set up and we wouldn't have to worry about > versioning issues when renaming fields. I'm not really sure why you'd want to do this. The numbering / tags in protocol buffers are more of an implementation detail to minimize the number of bytes in the payload and to provide a meaningful way to support the use of the protocol message across different languages. If you have a concrete use case, please give me an example. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
