Ryan, Thanks for the explanation. I¹ve been on vacation, so sorry for not responding quicker. Should I open up an enhancement jira for this?
doug On 10/29/12 8:47 PM, "Ryan Baxter" <rbaxte...@apache.org> wrote: > 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 >> > >
