That's a good idea but it doesn't solve the issue of converting the RPC received objects into a locally persistable objects. In my case, the user is loading a list but I want to pre-populate it with the latest list and have him/her manually refresh it. Thanks for your assistance
On Thursday, October 11, 2012 5:19:26 PM UTC+2, Joseph Lust wrote: > > It really depends how intelligent you want your store to be. For example, > if a user is perusing a set of N objects, and you hit the server up for 3 > of these objects, you'd want to first check your LocalStorage cache for any > of those 3 objects (say 2 hits), via a proxy cache, and relay on the RPC's > for the (1 object) cache misses. This way, after playing around a little > bit in your app, most requests will be local cache hits and you minimize > request time and UI latency. Then you also need to limit what's in the > cache, so you need a LIFO approach like LinkedHashMap. To do this however, > there is no need to change your GWT-RPC code, but rather make requests to > you client side caching layer, not directly to the RPC, and let that layer > make the RPC requests. > > That however is an intelligent caching strategy we used for 10K expensive > objects. I suspect you want a passive GWT-RPC cache which would be most > readily achieved by exploiting the browser cache with cache headers, but > consider how you'll expire those objects (TTL?). > > Sincerely, > Joseph > -- 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/-/oN4As2cOJwIJ. To post to this group, send email to [email protected]. 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.
