Thanks for the responses! @Jens The payload is already on the server. I send it up as an xml file that gets parsed and converted to a Java object. The upload and conversion happens as a backend process independent of any client interaction. This payload object then gets serialized and sent to clients in response to rpc requests. So the object is uploaded once and then delivered to many clients many times.
@Jamie I've already done this. I'm caching the actual RPC responses. My RemoteServiceServlet looks at the RPC request and serves the requested item from cache if available. Sorry, I should've made this clear in my original post. So why am I considering a caching proxy? Because our app is hosted on Google App Engine and is using its distributed cache, and I don't have control over when my cached items get evicted. App Engine doesn't always seem to be super-responsive to the RPC requests (even though I'm using an always-on instance). Since the cached items don't change frequently and aren't client-specific, I thought I would experiment with a proxy cache in front of my system and see how it works. At least I would have better control over cache expiration. @Benjamin Hopefully the above makes my situation clearer. I already avoid the serialization overhead on the server because I'm caching the actual RPC response. So the only particular performance advantages I hope to gain are: - avoiding creation and serialization of the RPC request on the client - avoiding deserialization of the RPC request on the server - better performance of Varnish cache serving quasi-static resources from a cache I can control than App Engine servicing RPC requests from a cache that I can't control. I'm assuming the first 2 are negligible and the 3rd one is what I'm curious about. It's an experiment. All I want to do is retrieve RPC-serialized objects from the server via GET, with two very simple request parameters as part of the url path. GWT-RPC already happens over HTTP, and what I'm looking to do wouldn't require any "frankensteining" that I can see. It should just take a couple lines in a RemoteServiceServlet and a couple on the client. Alternatively I'd be happy with any other method of serialization that would allow me to leverage my existing code that uses RPC serialization with custom field serializers, and to serve this serialized object via HTTP GET. I'd also be open to modifying my serialization process, but my hierarchy of serializable classes is pretty deep and I don't really want to create JS overlays or RequestFactory proxies for all of them. GWT-RPC is already a functional serialization mechanism for getting my object to the client. I just want to request the object slightly differently. ----- So I'm wondering: 1) is there a way to get the permutation strong name from the client even when running in Hosted Mode? 2) Are there gwt client libraries I can use to parse the RPC response and deserialize the object manually on the client, outside of the standard GWT-RPC request context? Maybe a client-side equivalent of RPC that has a decodeResponse() method? 3) Why are serialization policies permutation-specific? It seems that the serialization policies generated during a single compile should be the same. Why would they need to be browser- or locale-specific? My existing system is caching RPC responses, and it just occurred to me that I may be caching an RPC response serialized with a given serialization policy but then serving it to a client that will then deserialize it with a different serialization policy. Seems like a bad idea. Both serialization policies would be generated from a single compile but might represent different browsers or locales. So far in our production system accessed by many different browsers, there haven't been any problems. Thanks again for any wisdom about the above, Peter -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/QdPhdGKEY5UJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
