Toolkit is fast turning into the dumping ground of mozilla-central. Once upon a time the idea was simple. Any code that could be usefully shared across multiple applications (and in particular code that wasn’t large enough to deserve a module of its own) would end up in Toolkit. The rules were pretty simple, any code in there should work for any application that wants to use it. This didn’t always work exactly according to plan but we did our best to fix Seamonkey and Thunderbird incompatibilities as they came along.
This worked great when there was only one Firefox. Shared code went into m-c/toolkit, Firefox specific code went into m-c/browser. There were always complaints that more of the code in browser should be moved to toolkit so Seamonkey and other projects could make use of it but otherwise no big issues.
Now we have more than one Firefox: Firefox for desktop, Firefox for Android, B2G, Metro and who knows what else to come. Suddenly we want to share code across different Firefoxen, often different sets depending on the code, often depending on other pieces of code like services that aren’t available in all other applications. Keeping the rules as they stand now means that Toolkit isn’t the correct place for this code. So what do we do about this?
There only seem to be two sensible choices. Either we change the Toolkit rules to allow code that may not work in some applications, or we create a new catch-all module for this sort of code. And really those are just the same but with the need to find a new module owner for the new module. I’m going to ignore the third option which is to create a new module for each new piece of code like this as being hopelessly bureaucratic.
So, I’m proposing that we (by which I mean I as module owner) redefine the rules for Toolkit to be a little broader:
- Any code in Toolkit should be potentially useful to multiple applications but it isn’t up to the author to make it work everywhere.
- Patches to make code work in other applications will be accepted if not too invasive.
- Any code in Toolkit that is called automatically by Gecko (like the add-ons manager) must work in all applications.
Any strong objections?
There’s probably something to the idea of making a “browser-common” module for the code that’s shared across Firefox implementations but not generally applicable.
Hmm, do you have any examples of want-to-share-but-only-among-foxen code? I’m trying to think of what that might be. For example, the sync stuff… except for that bug trying to make it work in Thunderbird (and presumably Seamonkey would already be interested even for juts bookmarks/history bits). There’s the devtools… but why shouldn’t Composer (or whatever it’s called these days) get that? 🙂
SeaMonkey already has Sync, though we’ve had to port all the Frontend-based code for it ourselves, and we are basically copying new code (almost) line for line for porting.
My concern with the above rules are: “but it isn’t up to the author to make it work everywhere.” We should strive to make it “not included” into other products at all if it is not directly made available for other products.
Also “should not require features/methods/etc. that are designed/implemented/ in an app-specific folder” (such that if feature X in browser/ is not required for a potentially-cross-app feature in toolkit/) and we should not require Firefox Implemented Toolkit Module Y, in cross app potential module Z, especially if module Z is already used cross App.
Basically Stuff that *is* cross browser should stay cross browser without breaking, and stuff that can be cross browser should be able to be made cross browser with [just about] only changes in toolkit/ And lastly we should not include tests/features that are broken by default in non-conformant applications. Even if core code doesn’t call them directly.
“Any code in Toolkit should be potentially useful to multiple applications but it isn’t up to the author to make it work everywhere.”
… but the code and APIs should be as generic as possible, as far as this makes sense for what your code is meant to be used for. That is, toolkit code shouldn’t cater for a particular set of applications out of laziness. If done right, this will also mitigate the need for too invasive changes down the road (your second point).
A browser-common module seems reasonable to me as well, but it has a similar caveat: code shouldn’t be put there just to avoid thinking about other applications and designing your code and interfaces accordingly, although in some cases it might make sense to land in browser-common first and move to toolkit later.
So… you lead off with “Toolkit is fast turning into the dumping ground of m-c” which makes it sound like a problem. And then you note that there’s a class of code we can’t currently dump in there, and propose a rule change to allow even more code to be dumped into toolkit, with a split in terms of which code does and doesn’t need to be cross-platform.
Frankly, I don’t think we should have a dumping ground in m-c, and I don’t believe anyone would successfully propose one if we were starting now. I believe in strongly defended and coherent code modules, and I reject the implication that identifying and clarifying strong ownership constitutes bureaucracy or unnecessary overhead. (There’s obviously an extreme case we don’t want to hit.)
Toolkit as it stands has an owner and 25 peers, covering a collection of ~3000 files and half a million lines of code. Even a few years ago it wasn’t what I’d call strongly owned, and I think it’s even fuzzier now. I believe we can and should be able to reform Toolkit into a set of coherent modules with strong ownership, without devolving into “new module for every chunk of code” or any other path to madness, and slot most new code under one of those modules, and end the “dumping ground” mentality.