We want to flush the cache for specific URL's, for instance when a
gadgetspec XML should be refreshed (by the developer or by us) because
an update was released.
But our main issue has to do with our container specific container.js,
defined in opensocial-current/feature.xml. We host this file and others
separate from Shindig on our static content servers. When deploying a
new version of our main website we want to be able to refresh these
Javascript files which are being caching in Shindig.
I did notice the 'inline' attribute, but because the static content
servers have an expire header that is far in the future and we normally
use unique names per file version in the website to deal with this, I
don't really see a way to make users or shindig download the new
container.js now. (And if I remember correctly it also gave us some
problems with the right order of loading the scripts.)
Maybe we're doing this the wrong way? Any help is appreciated.
Thanks.
ps. Sorry for my late response. I had trouble with my e-mail.
Marijn
For what use-case do you want to flush the cache? We haven't added the
ability for gadget developers/end-users to do this on demand but there has
been some dicussion of this on the spec list. Your observation about
nocache=1 is correct and is implemented that way to allow the gadget to
continue to be served if the HTTP request for the gadget spec fails as we
can still use the one on the cache in the interim and forcibly flushing it
would have prevented this.
-Louis
On Wed, Aug 6, 2008 at 6:53 AM, Marijn Speelman <[EMAIL PROTECTED]> wrote:
Is there a way to refresh the http response cache (which caches manifest
files, rewritten content, internal js feature files, proxy requests),
without restarting Shindig? Or what could be the best place to build this
in?
I don't think nocache=1 works for refreshing everything. For instance, when
using nocache=1 the in-memory GadgetSpec cache is refreshed, but as far as I
can see the entry in the http response cache is not (it's bypassed
completely). Could this theoretically result in two different versions of
same gadgetspec?
Thanks,
Marijn