On 24-Jul-09, at 9:11 PM, BobV wrote: >> 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.
From a dev perspective, it might be easiest if we could make methods optional directly on the method. It more closely matches our current modus operandi w.r.t. thrift - the new parameters are added directly to the method, while the old ones are simply removed. Regardless of the method compatibility story, it would be very helpful to have an RPC validation utility: given this set of client RPC manifests, can we successfully parse the requests? >> 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. Good point- I'm not sure I can really offer a good example that would justify this effort. The only reason I can see to do it would be to prevent field renames from breaking serialization compatibility (something we take for granted today). That can be mitigated through developer education and as it stands, there's nothing in this model that would prevent us from generating GWT-compatible stubs from our thrift IDL. Thanks for answering my questions, Matt. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
