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
