There's actually a larger problem here and it affects more than just the rpc calls. One problem area is upgrading a cluster of shindig machines to insure that iframe content matches up with container js and forced-libs js content.
If you upgrade the cluster in-place you'll end up with requests for javascript going to the old build which is then cached by the browser. This is especially problematic because shindig always responds 'not-modified' to an IMS request when a v= param is present. If you have session affinity or other load balancer tricks you might not have this problem, however with a CDN in place the request for the JS content comes from the CDN host, not the user's browser. The solution used at hi5 was to add a 'generation' param to all versioned URLs. To do the rollout you then did: Rolling upgrade of hosts from v to v+1 Bump generation number Rolling restart of all hosts One possible solution is to compare the v= param the browser sends with the internal hash-code as calculated by the server. If they mis-match you can set low expiration value. (Although this still doesn't help with IMS requests..) The other idea is to have separate instances and change the parent path on a per-build basis for all gadgets/js requests. /opensocial-v1/gadgets/js /opensocial-v2/gadgets/js This has a nice side effect that you can deploy both versions side-by-side and drain down old for new. On Thu, Jun 11, 2009 at 1:07 PM, John Hjelmstad <fa...@google.com> wrote: > On Thu, Jun 11, 2009 at 1:46 AM, Kevin Brown <e...@google.com> wrote: > > > Realistically speaking, 'new' channels aren't going to be an issue. All > new > > browsers (and new browser versions) will use postMessage. We have a > channel > > that is 'fast enough' for all legacy browsers, and over time we will > remove > > libraries rather than add them. > > > > The reasons why we might add a new channel: > > > > 1. Some big security problem with an existing channel. Most likely we > will > > just switch back to IFPC for the browser(s) that are affected if this > > happens. IE 6 is really the only browser where this is a significant risk > > -- > > all other browsers (including IE7) are on an auto update path that will > > make > > the other legacy channels irrelevant by the end of the year. > > > Agreed. > > > > > > > > 2. I can't think of any other good reason. Vanity? > > > I shudder at the prospect of adding yet more rpc code for vanity :) > > > > > > > > The real issue is going to be code compatibility itself. Your proposed > > solution wouldn't make any difference if the code isn't compatible. > > > > I stand by what I've said for nearly 2 years on this issue, which i that > > the > > only viable option for the rpc feature is for containers to source the > file > > directly from the gadget server. Every other approach has been full of > > compatibility bugs. > > > +1, bottom line. > > --John > > > > > > > > On Wed, Jun 10, 2009 at 10:03 PM, Brian Eaton <bea...@google.com> wrote: > > > > > On Wed, Jun 10, 2009 at 6:57 PM, John Hjelmstad<fa...@google.com> > wrote: > > > > I don't know of > > > > any way that one transport would ever talk to another, so the best we > > can > > > do > > > > in such failure cases is to fall back to some common transport that > all > > > > browsers support. So it's critically important that integrations > happen > > > > properly. It just doesn't work for containers to cache some stale old > > > > version of rpc.js if the library is changing. > > > > > > Hmm. This feels wrong. What if the container passed acceptable > > > transport types on the gadget render URL instead, then the gadget > > > picked from that list? > > > > > > That way there would be no problem if the container didn't support > > > RMR, but the gadget did. > > > > > >
