Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.5.0
-
None
-
None
Description
Here's the mail list discussion.
From: Ryan Baxter <rbaxter85@apache.org>
Reply-To: <dev@shindig.apache.org>
Date: Mon, 29 Oct 2012 20:47:35 -0500
To: <dev@shindig.apache.org>
Subject: Re: Handling missing gadget url
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 <daviesd@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?