designoir
On extensions and jetpacks
Sonntag, 10. Jan ’10Mike Connor wrote:
The Personas and Jetpack projects were experiments designed to make extending the platform easier, and dramatically reduce the overhead involved in version updates/UI changes. We knew from the beginning that we would have to trade off truly limitless customizations to produce a more stable API/pseudo-API […]
This is a strategic product decision, intended to grow our developer ecosystem and broaden the scope of potential developers as much as possible, and deliver a much better user experience with customizations across core application updates. Deprecating the old systems in favour of the new systems is a required part of the strategic plan, because it is not enough to simply build a better system, we must migrate our users and our developer ecosystem to that system to reap the benefits.
In this context, I think deprecation includes the intent to remove the thing after a transitioning period. If I got this wrong, please tell me so and stop reading here.
If removing the current system is indeed part of the plan, then I don’t understand the reasoning. The last quoted sentence says that the need to migrate users and developers to a better system implies the need to deprecate the current one. But once a truly better system is widely available, making it easier to write and maintain appealing extensions, then developers will migrate, users will follow. Why wouldn’t they?
This would fail if the new system was actually less attractive (e.g. harder to learn) than the current one, but that would undermine the whole campaign anyway and make a forceful migration unfitting.
It would also fail in cases where the new system lacks capabilities of the current system (it needs to lack some, for it shouldn’t inherit the compatibility issue). Trashing the current system wouldn’t magically migrate extensions depending such capabilities, it would rather trash them as well. Would this be acceptable if 10%, 30%, or 50% of the current extensions were affected, including some of the more popular ones? Are we, and if so, why are we confident that the remainder would be sufficient for maintaining our lead in extensibility rather than pulling us down to Chrome’s level? How would users who already opt out of major updates because of their favorite extension react to this? Would losing them be better than letting them wait for an extension to become compatible?
It seems wise to me to allow a smaller set of dedicated people to create traditional extensions and indeed maintain them over years. Carrying around a minority of these extensions doesn’t mean you couldn’t reap any benefits. You’d still get more developers involved in the new system, you’d still get people to depend on fewer traditional extensions.
9 Antworten auf On extensions and jetpacks
-
David Naylor meint 10.01.2010, 22:03:18:
You have some very good points.
I hope the Firefox dev leads have enough sense to not make a big mess of this.
-
Tony Mechelynck meint 10.01.2010, 23:13:11:
I fear that concerning Firefox, now that “Thus Spake the Voice from On High”, Firefox developers will have to follow willy-nilly. I still entertain the hope and belief that SeaMonkey developers will exercise more wisdom, and pick up the extension system they just adopted from that very Firefox which is going to drop it, the way they picked up and cherished the Suite when the Mozilla People In Power left it out in the cold.
-
Omega X meint 11.01.2010, 00:30:32:
Since Mr. WON’T FIX has chimed in, I think the community needs to stay focused and chip away at the current reasoning and force them to only replace the core extension and theme systems when the replacements are ready, not before then. Currently, they are most definitely NOT ready.
-
Al Billings meint 11.01.2010, 01:58:30:
“If I got this wrong, please tell me so and stop reading here.”
You got it wrong.
-
dao meint 11.01.2010, 02:28:13:
Unfortunately, I don’t think I’ve got it wrong after all. Even after Connor’s update, I still seem to see the intent to eventually get rid of the current system, except that there’s thinking we could get there with super-rich-yet-restricted APIs that would allow all relevant customization to be implemented. It’s said that we’re not “anywhere near the point where we can look at the old-style extension model and claim it’s not needed anymore,” but I sense that we’re working towards it, and I’m afraid at some point somebody would arbitrarily declare success. I would be more pleased if I was presented with a plan B in case the new system didn’t meet some important criteria, or if the whole deprecation idea came up naturally once we had reached the point where jetpacks actually provided all we need.
-
Mossop meint 11.01.2010, 03:18:21:
I’m against completely removing support for the old style extensions unless you really can do everything in Jetpacks that you could before (and in fact the new superpower concept that will be coming with the Jetpack reboot might make this possible), and I would fight any attempt to do so. That said I am in favour of the kind of deprecation that means the old style are scarier to install and we mostly ignore breaking them with updates.
-
mikeal meint 11.01.2010, 06:29:41:
Reality check.
Everything is going out of process. First plugins, then extensions, then the entire content space will all be in separate processes. The only way to have code work between those processes will be through message passing.
Jetpack makes building extensions that work cross process significantly easier and provide an API you can use today to write an extension that will be supported cross-process indefinitely in the future with no changes to your jetpack extension.
It is easier to port 99% of the existing extensions to Jetpack than it is to make them work cross process. Unless your extension is Firebug, you will have an easier time moving to Jetpack than fixing for electrolosis.
-
Mike Beltzner meint 11.01.2010, 07:20:40:
You’ve got it wrong.
First off, as I think you know, Connor’s been working more on Weave than he has been on Firefox lately. While he spoke strongly about a strategic way to promote migration, you are more in the loop on the upcoming product plans than he is.
JetPack is a technology we’re investing in (as you know – it’s on our teams’ goals list!) and we think that it has the potential to be a platform which can be used as the primary means of customizing Firefox and the user’s web experience, but outright removal of the existing extension technology isn’t something that’s been discussed at all yet.
-
@mikeal: Traditional extensions would reside in the chrome process, not in a separate one. Of course, this means they could still crash the entire browser or slow it down by accessing the content area synchronously (but many don’t access the content area). So ideally, they wouldn’t work any worse than they do today in an multi-process environment. There would also be asynchronous APIs, allowing extensions to benefit from the new architecture by migrating softly. It’s not clear to my why you think this would be harder than re-implementing them as jetpacks. Besides, I should note that I’m still concerned that many extensions simply couldn’t be jetpacks. I have great trouble thinking of any of the extensions I created as jetpacks: http://en.design-noir.de/mozilla/
@beltzner: While Connor works primarily on Weave, I think he’s still more involved in overall project guidance than I am, and indeed he referred to a consensus among those leading the project. My impression of what he wrote is also consistent with how I perceived Benjamin’s and Shaver’s views in December, although maybe they also implicitly meant that a minority of traditional extension /might/ still exist in the background — like Connor, they didn’t actually say it, as far as I remember. I think it’s understandable that terms like deprecation have certain connotations, and if you don’t avoid or explain them, you get people concerned. I was certainly aware of the investment in Jetpack and don’t have a problem with that by itself.
