Orkut's sandbox caches your gadget to improve latency. This is undesirable during development, so to bypass caching on a given Orkut page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
<api.kur...@google.com> wrote: > Orkut's sandbox caches your gadget to improve latency. This is > undesirable during development, so to bypass caching on a given Orkut > page, please append &bpc=1 to the URL of the page itself:
Arne - it's cool to be able to not cache the gadget, but this brings up a problem which I mentioned in another thread ("Unofficial bugs"). If gadgets are cached AND the underlying API implementation changes (which, if experience with facebook taught us anything, is very possible), it will be a big problem. If the container changes its implementation, all the cached apps would break. At which point can app developers "fix" and "adapt" their applications then? Perhaps, if you really will cache javascript, there should be some revision number for the container's implementation. When it changes, the app developers have a chance to upload a script with the new revision number, so that (potentially) millions of users aren't stuck having to re-add the application.
Greg
On Nov 4, 4:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
> On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
> <api.kur...@google.com> wrote: > > Orkut's sandbox caches your gadget to improve latency. This is > > undesirable during development, so to bypass caching on a given Orkut > > page, please append &bpc=1 to the URL of the page itself:
These are valid concerns, and we're aware that gadget developers don't want to get stuck between API versions and caching. For the first issue, the cache lifespan is only an hour, so users with older versions of the gadget will only be out of sync for a relatively short period of time. Secondly, you'll notice that the <Require feature="opensocial-0.5" /> contains a version number. The plan is to release a higher version API while still supporting a lower version number for a short period of time, so that developers are able to port their apps while minimizing downtime due to breaking changes in the API. We won't be able to guarantee this for all changes (if the underlying infrastructure changes, for example) but we'll certainly be working hard to minimize the amount of pain that such changes will bring.
~Arne
On Nov 4, 8:09 am, EGreg <heyg...@gmail.com> wrote:
> Arne - it's cool to be able to not cache the gadget, but this brings > up a problem which I mentioned in another thread ("Unofficial bugs"). > If gadgets are cached AND the underlying API implementation changes > (which, if experience with facebook taught us anything, is very > possible), it will be a big problem. If the container changes its > implementation, all the cached apps would break. At which point can > app developers "fix" and "adapt" their applications then? Perhaps, if > you really will cache javascript, there should be some revision number > for the container's implementation. When it changes, the app > developers have a chance to upload a script with the new revision > number, so that (potentially) millions of users aren't stuck having to > re-add the application.
> Greg
> On Nov 4, 4:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
> > I have created a Greasemonkey script for firefox, which will append > > &bpc=1 automatically to the application pages.
> > On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
> > <api.kur...@google.com> wrote: > > > Orkut's sandbox caches your gadget to improve latency. This is > > > undesirable during development, so to bypass caching on a given Orkut > > > page, please append &bpc=1 to the URL of the page itself:
This is a very helpful script, and bpc=1 is indeed added to the end of the URL, but it still caches. Not only the gadget source, but it also caches what is returned from a remote server as a result of an _IG_FetchContent call.
Why can't caching just be turned off in the sandbox for everyone by default?
Even so, caching the remote data may be an additional problem...
The server I'm being routed to is: un64mq1e-a.modules.com
Ron
On Nov 4, 3:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
> On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
> <api.kur...@google.com> wrote: > > Orkut's sandbox caches your gadget to improve latency. This is > > undesirable during development, so to bypass caching on a given Orkut > > page, please append &bpc=1 to the URL of the page itself:
> These are valid concerns, and we're aware that gadget developers > don't want to get stuck between API versions and caching. For the > first issue, the cache lifespan is only an hour, so users with older > versions of the gadget will only be out of sync for a relatively short > period of time. Secondly, you'll notice that the <Require > feature="opensocial-0.5" /> contains a version number. The plan is to > release a higher version API while still supporting a lower version > number for a short period of time, so that developers are able to port > their apps while minimizing downtime due to breaking changes in the > API. We won't be able to guarantee this for all changes (if the > underlying infrastructure changes, for example) but we'll certainly be > working hard to minimize the amount of pain that such changes will > bring.
> ~Arne
> On Nov 4, 8:09 am, EGreg <heyg...@gmail.com> wrote: >> Arne - it's cool to be able to not cache the gadget, but this brings >> up a problem which I mentioned in another thread ("Unofficial bugs"). >> If gadgets are cached AND the underlying API implementation changes >> (which, if experience with facebook taught us anything, is very >> possible), it will be a big problem. If the container changes its >> implementation, all the cached apps would break. At which point can >> app developers "fix" and "adapt" their applications then? Perhaps, if >> you really will cache javascript, there should be some revision >> number >> for the container's implementation. When it changes, the app >> developers have a chance to upload a script with the new revision >> number, so that (potentially) millions of users aren't stuck >> having to >> re-add the application.
>> Greg
>> On Nov 4, 4:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
>>> I have created a Greasemonkey script for firefox, which will append >>> &bpc=1 automatically to the application pages.
>>> On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
>>> <api.kur...@google.com> wrote: >>>> Orkut's sandbox caches your gadget to improve latency. This is >>>> undesirable during development, so to bypass caching on a given >>>> Orkut >>>> page, please append &bpc=1 to the URL of the page itself:
: // Disable caching completely and fetch fresh content every time -- !! Try to avoid using this !! _IG_FetchContent("http://news.google.com/?output=rss", callback, { refreshInterval: 0 });
This should be fine for development purposes.
I'm seeing a lot of cases where people are using &bpc=1 but their browser continues to cache the old code. If you're still seeing old data, can you try disabling your browser cache and seeing if the problem goes away?
~Arne
On Nov 6, 6:22 pm, ronman <ron.new...@gmail.com> wrote:
> This is a very helpful script, and bpc=1 is indeed added to the end of > the URL, but it still caches. > Not only the gadget source, but it also caches what is returned from a > remote server as a result of an > _IG_FetchContent call.
> Why can't caching just be turned off in the sandbox for everyone by > default?
> Even so, caching the remote data may be an additional problem...
> The server I'm being routed to is: un64mq1e-a.modules.com
> Ron
> On Nov 4, 3:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
> > I have created a Greasemonkey script for firefox, which will append > > &bpc=1 automatically to the application pages.
> > On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
> > <api.kur...@google.com> wrote: > > > Orkut's sandbox caches your gadget to improve latency. This is > > > undesirable during development, so to bypass caching on a given Orkut > > > page, please append &bpc=1 to the URL of the page itself:
> Why not flush the cache whenever there's a new api release is pushed > out?
> (Dan)
> On Nov 5, 2007, at 8:57 AM, Arne Roomann-Kurrik (Google) wrote:
> > Hi Greg,
> > These are valid concerns, and we're aware that gadget developers > > don't want to get stuck between API versions and caching. For the > > first issue, the cache lifespan is only an hour, so users with older > > versions of the gadget will only be out of sync for a relatively short > > period of time. Secondly, you'll notice that the <Require > > feature="opensocial-0.5" /> contains a version number. The plan is to > > release a higher version API while still supporting a lower version > > number for a short period of time, so that developers are able to port > > their apps while minimizing downtime due to breaking changes in the > > API. We won't be able to guarantee this for all changes (if the > > underlying infrastructure changes, for example) but we'll certainly be > > working hard to minimize the amount of pain that such changes will > > bring.
> > ~Arne
> > On Nov 4, 8:09 am, EGreg <heyg...@gmail.com> wrote: > >> Arne - it's cool to be able to not cache the gadget, but this brings > >> up a problem which I mentioned in another thread ("Unofficial bugs"). > >> If gadgets are cached AND the underlying API implementation changes > >> (which, if experience with facebook taught us anything, is very > >> possible), it will be a big problem. If the container changes its > >> implementation, all the cached apps would break. At which point can > >> app developers "fix" and "adapt" their applications then? Perhaps, if > >> you really will cache javascript, there should be some revision > >> number > >> for the container's implementation. When it changes, the app > >> developers have a chance to upload a script with the new revision > >> number, so that (potentially) millions of users aren't stuck > >> having to > >> re-add the application.
> >> Greg
> >> On Nov 4, 4:40 am, Sahil <go.ahead.sa...@gmail.com> wrote:
> >>> I have created a Greasemonkey script for firefox, which will append > >>> &bpc=1 automatically to the application pages.
> >>> On Nov 3, 10:32 pm, "Arne Roomann-Kurrik (Google)"
> >>> <api.kur...@google.com> wrote: > >>>> Orkut's sandbox caches your gadget to improve latency. This is > >>>> undesirable during development, so to bypass caching on a given > >>>> Orkut > >>>> page, please append &bpc=1 to the URL of the page itself:
|
