Thanks for the feedback. To summarize the feedback I'm getting: we're already developing a new desktop API; it'll be like Chrome's and we'd like Fennec to be able to share a lot of code with Desktop.
I'm happy that we're going to be enabling easy translation of addons from Chrome to Firefox. Without much to go on, I'd hazard a guess that this is a) not actual parity with the Chrome APIs, and b) most of what we want from Chrome is the most well used subset of the API, which is actually fairly small (e.g. content-scripts). Much of what I am proposing of extensions/extension points is an object in the existing manifest to cleanup the various barnacles that Chrome's format has picked up over the years: omnibox, file_*, chrome_*_overrides, storage attributes are the most obvious examples. Having the top-level of the manifest as a dumping ground for functionality we steadily expose to addons means we will be growing our own barnacles on our own monolithic format for some time. Looking at [1], it seems that our work so far on this has implemented only the non-contentious attributes (this is a good thing!): we haven't yet copied any of Chrome's oddities, and we haven't had time to invent our own. This is not yet a finished product, we need to expose multiple *ahem* points of extension, and I'm suggesting we expose them in a relatively structured way. More generally, and probably less helpfully: Chrome's addons API learned from ours, and then leap-frogged it. While we have a very rare opportunity to do a redo on anything, it would be sad that the best we can do is achieve parity with Chrome. Furthermore, given that the browsers we ship are the same but different (desktop, Android, iOS, FxOS), and that we want to increase the importance of addons on all these platforms, only achieving parity with an API that is only supported on desktop[2] seems troublesome. [1] https://bug1175770.bmoattachments.org/attachment.cgi?id=8623994 [2] http://www.omgchrome.com/chrome-android-extensions-not-planned-ama/ Many regards and thanks, – James On Mon, Jul 27, 2015 at 3:49 PM, Margaret Leibovic < [email protected]> wrote: > Hi James, > > Thanks for starting this conversation. If you're looking to support > cross-platform APIs, I would encourage you to get in touch will billm, > since he's been leading the work to create a new e10s-friendly extension > API for desktop [1], and we've discussed adding support for Android as well > [2]. The details for the Android side haven't been very fleshed out yet, > but the general idea would be to try to share API implementations where it > makes sense (i.e. where we don't have different UI to worry about). > > I realize that iOS does not have the luxury of sharing the same > toolkit-based add-on manager logic that Android/desktop use, but I think we > should at least try to support similarly structured add-ons from a > developer point of view. Looking at the wiki page you wrote up, I'm not a > huge fan of inventing another add-on manifest system. In the new extension > API world, I believe add-on manifest files will look similar to the Chrome > extension manifest.json format [3], so it could be good to look at that for > ideas. > > Margaret > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1161828 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1185785 > [3] https://developer.chrome.com/extensions/manifest > > On Mon, Jul 27, 2015 at 5:21 PM, Ben Bucksch <[email protected]> > wrote: > >> It seems you're more defining a module system. >> >> Personally, I don't like strings in code. Instead of >> >> registry.getExtensions('firefox.home.tileCollections') >> >> can't we do rather do: >> api.firefox.home.tileCollections >> ? >> >> Most importantly, however, please do NOT let me define all used APIs in a >> manifest. My extension is modularized, and even within a module, I keep >> things separated in files. I want to have everything related to a >> functionality in that one code file. This helps code comprehension, allows >> easy add/removal of features, and avoids merge conflicts. If every API ever >> used anywhere must all be in one file, this file is bound to have constant >> merge conflicts when merging branches. >> >> The typical solution for that are imports at the top of the source code >> file. But IMHO, even that is annoying (conflicts at the top, changes not >> confined to function). Why not just quickly scan the source code for "api." >> and then load stuff? The JavaScript compiler has to load the ext code files >> at ext load time anyways, right? As soon as it tries to resolve api. , you >> resolve the extension point and you're at the same place as with your >> manifest file. >> >> Ben >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
