There's something I don't understand.Why do you cache the XML for such a short time? Gadgets don't change every hour, or even every day. Why not parse the XML once and save it for a few days? That way the servers make fewer requests and parse XML less often.
On Fri, Aug 29, 2008 at 7:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > In addition to what Ian has said, there are actually two caches: > > - HTTP level. Generally best implemented as a distributed cache, since > there > will be lots of files here. > - Manifest (Gadget / message bundle xml) level. Best implemented as an > in-memory cache. > > The default implementations of both caches are in memory, but if you're > scaling up I'd recommend using a distributed cache for HTTP (and strongly > recommend keeping the in-memory cache for the xml files). > > As far as caching policy goes, the specification *requires* that we do two > things: > > 1. Honor HTTP cache-control headers by default. > 2. If the user specified a parameter in the request (say, in getProxyUrl or > makeRequest, or by rewriting), honor the cache time that they've specified. > > For gadget specs, the rules are not well defined, but the de facto standard > is to cache the files for a reasonably long time period (usually 1 hour). > > On Fri, Aug 29, 2008 at 3:45 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > For Java Shindig: > > > > The default cache is entirely in memory, wont page to disk and doesn't > have > > distributed capabilities, but is light fast and works perfectly well. > > > > However > > In the current code base there is an implementation of the CacheProvider > > for EhCache which will do distributed Cache for you. > > > > Its not active by default, you need to add the EhCacheGuiceCacheModule to > > the list of modules that are loaded. > > The configuration is in 2 places, ehcache.properties for the shindig > > specific settings, like JMX stats and the location of the ehcache xml > > configuration file, currently on the classpath at > > /org/apache/shindig/cache/ehcache/ehcacheConfig.xml > > > > You should consult ehcache documentation to configure distribution and > > paging to disk http://ehcache.sourceforge.net/EhcacheUserGuide.html > > > > I have an Apache JCS implementation in waiting to go in, and there may be > a > > memcachd impl in the pipeline. > > > > > > Code: > > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > > src/main/java/org/apache/shindig/common/cache/ehcache/ > > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > > src/main/bundle/ehcache.properties > > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > > src/main/bundle/org/apache/shindig/common/cache/ehcache/ehcacheConfig.xml > > > > The location may change as we get closer to a 1.0 release. > > > > HTH > > Ian > > > > > > > > > > > > On 29 Aug 2008, at 10:14, Eran Galili wrote: > > > > Hi, > >> > >> I started implementing a container using shindig as my gadget server and > I > >> have a few questions regarding the way shindig gets and caches the > gadget > >> XML. > >> > >> First, I'd like to know what's considered the best practice for the > >> expiration time of cached gadgets? Does it have to be in some kind of > >> range > >> for my container to be spec compliant? > >> > >> Secondly, does shindig cache the gadgets only on the machine's memory, > or > >> does it also support using a distributed cache? If i set a very long > time > >> for my container to update the gadget XML (and perhaps allow the > developer > >> "update me" functionality), would it be reasonable to save it on my > >> database > >> (maybe save it already parsed)? > >> > >> Also if i keep an "Application Directory" of approved apps that i allow > on > >> my container, is it really necessary to send the gadget XML URL to when > >> sending a gadget rendering request? If i implement my own gadget server, > >> could i simply send an application Id (managed by my site) and on the > >> server > >> side get the appropriate URL for that application (or even the XML > itself > >> from the cache)? > >> > >> I'm asking these questions because i think I'm missing something. I > would > >> like to minimize the amount of times my servers have to parse the gadget > >> xml. Saving the gadget spec already parsed would allow me to do that. > >> > >> Thanks in advance, > >> Eran > >> > > > > >
