On Fri, Feb 10, 2012 at 1:37 PM, Ian Hickson <i...@hixie.ch> wrote: > On Fri, 10 Feb 2012, John J Barton wrote: >> On Fri, Feb 10, 2012 at 10:58 AM, Ian Hickson <i...@hixie.ch> wrote: >> > On Fri, 10 Feb 2012, John J Barton wrote: >> >> >> >> Just to clarify, I want to see the layer you just outlined be >> >> standard so we can design iframe components and apps to mix and >> >> match. This can be two simple layers on the current messaging: 1) the >> >> connection ceremony, 2) the key/API format. >> > >> > No reason for it to be standard, just define it as part of the >> > protocol you are implementing over postMessage(). >> >> Ok, so I define it for my app. You write an iframe. You read my >> definition and I can load your iframe. Yay! >> >> Then Boris write an app. He defines it for his app. You change your >> iframe to deal with my app and Boris' app. Ok. >> >> Then Mark Zuckerberg and Larry Page define apps. Soon you are spending >> all of your money hiring devs to deal with connection protocols. >> >> Then maybe you will have a reason for a standard? > > Why would the connectivity part of this be the hard part?
Because the existing information on cross-domain iframe communications is incomplete and written in terms few Web app developers understand, the browser implementations are new and the error messages they emit are puzzling. Solutions for same-domain cases don't work for cross-domain. Async communications is hard to debug. > Each of these > apps has an entire protocol you'll have to reimplement if you want to > connect to it! The connectivity part is trivial in comparison. Probably not, at least to start. Most of the early efforts are just things like setting UI sizes or passing config strings. In the long run the essential difference between a JS library widget and an iframe widget will be asynchronous message passing. Libraries, tools, and languages features are gearing up to help. > > I'm all for people standardising their postMessage() protocols, though, > if they want to. Nothing is stopping people from doing so. public-webapps would seem to be an appropriate venue to begin the discussion, esp. since this is where the expertise on web messaging exists. jjb
