So the gadget XML is not cached on the server, but the metadata request is cached on the client? The NO_CACHE option looks like it is only used to tell shindig to render the gadget in debug mode. It is also specifically used for rendering gadgets not for caching in the container. The metadata caching functionality in the common container is lacking. Not only is it always cached, but the common container never purges the cache. It wouldn't be hard to check for whether the container is in debug mode and disable the caching. Unless we want to introduce a separate caching param for the container as well...
On Thu, Oct 25, 2012 at 9:57 AM, daviesd <davi...@oclc.org> wrote: > I have a scenario where a gadget is rendered from a known url, dropbox lets > say. If later on if I remove the gadget from dropbox and my container > tries > to re-render it I get the message > > Unable to retrieve spec for > https://dl.dropbox.com/u/xxxxx/gadgets/oauth2.xml. HTTP error 404 > > Which seems to come from AbstractSpecFactory.java within Shindig. > > However the call to holder.getGadgetInfo still returns the cached entry, so > there is no way for me to detect this scenario so that I can handle it > appropriately in my chrome elements (disable things). > > If the gadget url is missing on the very first render, then I get back a > error inside gadgetInfo that is passed to the navigateGadget callback. > > I¹m pretty sure I have caching turned off when I render the gadget. > > renderParams[osapi.container.RenderParam.NO_CACHE] = true; > > Any ideas on how to detect that the gadget xml spec has gone away on the > first scenario? > > Thanks, > doug >
