SGTM. Note that we're essentially duplicating (assumedly intentionally so) the window.postMessage() APIs which require specifying a target domain and whose connect event has a "source" and "origin" attribute specifying the window that sent the message. It might be valuable to just explicitly adopt those interfaces wholesale, substituting extension IDs for domains. It's an excellent point about connectExternal and startup ordering - in fact, one of the problems with window.postMessage now is that there's no guarantee that your message will be delivered if the target window has not loaded yet.
-atw On Tue, Jul 28, 2009 at 11:19 AM, Aaron Boodman <[email protected]> wrote: > > +chromium-dev > > I think this is great. I suggest creating a wiki page with a design > for this so that we can refer to it whenever we implement, and a bug > that refers to the wiki page. > > Up until now, we've been putting our designs here: > http://dev.chromium.org/developers/design-documents/extensions (see > "proposed api"), but that page isn't editable without a @chromium.org > account. > > I've been thinking we should move that content to the wiki so that it > is editable by all. So if you want, you could be the first. > > > Besides that, a few minor comments: > > 1. I think we should add a permission for inter-extension > communication once we have a permissions mechanism. That is, an > extension should have to declare in the manifest which extensions it > would like to contact. This is just a security precaution against the > extension accidentally leaking privileges if it gets XSS'd or > something. > > On Tue, Jul 28, 2009 at 10:58 AM, James Robinson<[email protected]> wrote: > > > > I think that extensions should be able to communicate with each other > > using message passing. Currently, it's possible to do something like > > this: > > > > var ext = new chrome.Extension('abcdefgh...'); > > var port = ext.connect('channel from another world!'); > > port.postMessage({"message": "im in ur channel"}); > > > > However, there are a few problems with this approach. First, it's > > probably a bug that it works. The more serious issue is that a > > onConnect event is fired at extension 'abcdefgh...' and there is no > > way for that extension to know that the port is not from a content > > script within the same extension but from another extension. An > > extension should be able to allow other extensions to open connections > > to it, be explicitly aware of where the connection is coming from, and > > then communicate with it using the existing chrome.extension.Port > > system. > > > > This would require two new APIs on the chrome.extension object, based > > on the ones presented in > http://dev.chromium.org/developers/design-documents/extensions/content-scripts > : > > > > // Open a channel to another extension with the provided ID. > > // If no extension with the provided ID exists, nothing happens. > > // Otherwise the chrome.extension.onConnectExternal event is fired > > // to all components of the extension with the provided ID each time > > // the method is called. > > // The channel can optionally be named. This name will be sent along > > with the > > // onConnectExternal event > > Port connectExternal(String ID, [String channelName]) > > 2. I think we can merge connect() and connectExternal() by adding an > optional param to connect() that specifies the target extension. If > omitted it defaults to the current extension. > > > // Fired when another extension opens a channel to this extension via > > // chrome.extension.connectExternal(). > > // If a channelName was provided, it is accessible via port.name. > > Event onConnectExternal(Object port) > > > > In order for an extension to know what the other side of a connection > > is I'd also propose adding the following property to the > > chrome.extension.Port class: > > > > // ID of the extension at the other side of this port. > > String senderID; > > > > An extension could check this field in the onConnectExternal handler > > and compare it to a whitelist/blacklist to decide whether to attach > > onMessage handlers. An extension might also want to expose some UI to > > the user listing all connected extensions. > > > > The other issue to address is startup order. The order in which the > > scripts within different background pages is not defined, which is > > entirely reasonable, but it means that doing the obvious thing: > > > > <script> > > var port = chrome.extension.connectExternal('abcdef..'); > > </script> > > > > would work unreliably depending on the exact order in which the > > background pages get loaded, the event handlers get registered, and > > the events are fired. To resolve this I think that all connectExternal > > () events be queued until each extension's background page has loaded, > > so that any handler registration code in top-level <script>s has a > > chance to run. > > This seems reasonable. It might be possible to be even cleverer if we > know who wants to connect to who by way of what they declare in their > manifests. > > - a > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
