All necessary information is comming in the RPC call. If you take a look into RemoteContextSerializationPolicy you can see how the HTTP connection is initiated. You don't have to take care about where are RPCs located because the call itself will tell you.
The drawback of "remote context" is that there is HTTP connection but you have always an option to switch to "local context" in production. There will be no overhead then. Regarding duplicate entries in RPC files... my advice is if your RPC files are generated correctly, your calls are working correctly, "don't touch it" :) Resolving serialization problems are one of the trickiest.... and if there are duplicate entries it is because the service/permutation apparently needs it there. You may reorganize your services to lower the number of same objects across them. On 23. Feb, 18:23 h., ed bras <post2edb...@gmail.com> wrote: > He,> to fetch them using HTTP connection to appropriate client. > > Indeed, that doesn't sound that bad, but I will need to maintan a mapping > between the moduleBaseUrl that I receive in the backend and the actual http > url of the module location where I can find the policy file. And these > mappings are different in development and production mode. > > But, if you think about it, it will probably be the best option if you want > to deal with policy files. The other little disadvantage would be the HTTP > communication whereas the files are located on the same server. > > But, that doesn't take away the disadvantage of having all these duplicate > entries in the policy files. > > What about implementing my own SerializationPolicy class and simple filter > on, for example the package name, to indicate if an object is allowed to be > serialized/deserialized.? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
