On Wed, Jun 4, 2008 at 9:58 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> > On Jun 4, 2008, at 9:36 AM, Kevin Brown wrote: > > On Wed, Jun 4, 2008 at 8:54 AM, Ian Boston <[EMAIL PROTECTED]> wrote: >> >> I did the ehcache impl in SHINDIG-279 about 2 weeks back, but there are >>> some other requirements that have come in that this doesn't take into >>> account, like variable cache timeout on an payload by payload basis (from >>> the headers of the httpresponse on the remote server). However, that >>> should >>> be easy enough to add (happy to do it if there is demand). >>> >>> There is also a Apache JCS cache implementation, which requires that the >>> key and payload are serializable. For some reason which I haven't worked >>> out >>> yet they serialization tests pass on the objects, but the cache unit >>> tests >>> fail with JCS.... so that patch isn't working (yet, lack of time not tech >>> barrier IMHO). For Obvious reasons, Apache JCS would be the better >>> solution. >>> >>> One other cache worth thinking about is memcache. I believe there is a >>> JNI >>> binding to this, and although it takes non Java setup to make it work, >>> its >>> widely used. Apparently Memcached will be part of the Google App >>> engine.... >>> which I though I heard form someone would run java apps in the future? >>> (or >>> was that just a sensible suggestion) >>> >> >> >> I can't comment on the app engine parts, but there are several >> implementations of memcached clients for Java. Some are native java, some >> are JNI. >> >> Paul has some experience with this -- care to share? >> > > Memcache is good for what ails you. We're using the meetup.com / Greg > Whalin client from http://danga.com/memcached/ (with a bunch of site-local > hacks). Dustin Sallings library is also very very good ( > http://code.google.com/p/spymemcached/) > > In our current implementation we actually injected caching in the > contentfetcher. We maintain a whitelist of known/approved gadget spec URLs > and use the cached content wherever possible. > > This allows some nice features in our developer console, such as the > 'Refresh' button that injects content into the cache directly. > > We also have a CDN in front of our shindig servers. This caches the > rendered IFrames. I'm of the opinion that it's better to have a common > consistent app-bundle with only variations per-language/per-country. We put > the skin parameters and parentURL params in the hash portion of the url for > that very reason. No HttpCache?
