I feel this relates to the previous thread of how app (System) defines the inner component interfaces, like to use `Service.register(<method`)` instead of arbitrary event dispatching (although in the thread I also explained that I felt a correctly implemented message passing will benefit us more than method calls). If an app defined its component interfaces based on the method well, add-on may easily find out the hook points.
And I think there are some classic issues like compatibilities among different app "versions", which also somewhat relates to the Gaia train model. For example, if one hook point should be deprecated in next version System app, we should have a way to help add-ons to find out if it's current runtime is in the right version. I don't know whether most certified apps update the version number regularly, but if we want to keep the hook points work with add-ons well in the long term, we may need the contracts available during a clearly defined period. Components may also help. For example, maybe Gaia/Web/FirefoxOS components could be the de facto UI hook points for add-ons, while they can easily customize the UI with some pre-defined and adjustable priorities of components, rather than just modify the DOM tree arbitrarily. For headless components, we already have some instances like `ScreenManager`. Therefore a set of public hook points based on concrete design principles could be provided as instance methods naturally. 2015-12-01 13:45 GMT+08:00 Jonas Sicking <[email protected]>: > On Sun, Nov 29, 2015 at 11:39 PM, Fabrice Desré <[email protected]> > wrote: > > Hi Fred, > > > > thanks for starting the discussion on that! > > > >> Below are suggest hookpoint list and reason: > >> ---------------- > >> 1. text selection actions > >> allow addon to intercept selected text and make meanningful actions. > Ex: search, find definition > >> 2. Rocketbar instant suggestions > >> allow addon to intercept inputed text and pop related suggestion or > result. > >> Ex: weather in orlando, map disney swan hotel > >> (does that reminds anyone the ubiquity addon(2008-2010) from mozilla > lab?) > > > > These all look like useful extensions points. > > > > In general, I think each app owner should look at which features we > > want/can make accessible to add-ons and do the appropriate changes we > > need in the apps. One thing to remember is that injected scripts have > > access to the `window` and `document` objects, so anything we leak on > > these will be (ab)used by add-on authors. > > > > That also means that as we make changes to apps, we may have to maintain > > some backward compatibility to not break add-ons written for older > > versions. That's very similar to the situation we know with xul/xpcom > > add-ons: each time we want to make a non-backward compatible change to a > > public xpcom API, we check how many add-ons will be impacted and we warn > > add-on authors in advance. We also may have to enforce a min/max > > compatibility version check when installing add-ons that inject into the > > system app (and possibly all gaia apps). > > I think the idea of having gaia app developers think of places in > their apps that addon authors could hook into is a really good one. > > But rather than continue to expose the `window` and `document` as a > way to address those, I think we should add dedicated APIs that addon > authors can use. > > I think it would be really awesome if we added support for allowing > Gaia apps to implement their own APIs that are exposed to addons. > > Something like > > fireAddonCallback("callbackName", arg1, arg2, arg3).then((result) => > {...}); > > would go a really long way. Where the argNs and the result are > structured-cloned, allowing them to be passed between the gaia process > and the addon process. > > / Jonas > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > -- <http://about.me/snowmantw>Greg Weng http://about.me/snowmantw *Understand y f = f [ y f ] ; lose last remaining non-major friend* * -- Anonymous*
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
