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. > > >
