This thread worries me greatly. Somebody tell me we have a plan and
policy around this already. Please?
We're taking the regrettable but necessary step of killing off legacy
style extension "APIs"[1]. Necessary because e10s and the basic
impossibility of maintaining security, stability, performance, etc. with
a wide-open extension mechanism. Doing this at a time of weak market
share is... courageous[2]. Given our position, it's a bold move that
says we're willing to take the painful hit of pissing off addon authors
and users because we truly believe it is necessary to produce a
top-quality product. In short: better to have fewer users now with a
high quality product that has the ability to grow, than to retain more
users on a lower-quality product.
But to make the sacrifice worthwhile, that means we have to *be* a high
quality product. One with a competitive edge. Which means that people
have a reason to choose us over the alternatives. And while we can and
should look for other ways of doing that, via activity streams or
privacy or Accounts or better tab handling, our historical edge has been
extensibility and customizability. Firefox is sticky because people can
make it do what they want, things that they come to depend on enough
that they feel like they're missing out by switching browsers. (Even if
people don't *actually* make use of it, knowing that the capability is
there is powerful.)
That's my argument for why the default answer here should be "Heck yeah!
If we can provide something that other browsers don't, DO IT!" I could
describe it as a fairness/good faith argument instead: we just took away
a bunch of powerful tools from our users, claiming that it was for their
own long-term good, so it behooves us to give back whatever we can in a
more manageable form, in order to provide that promised good.
The thing tempering this answer, of course, is that we don't want to
paint ourselves into another corner[3]. The extension API is on its own
standardization treadmill, and extension APIs that change or differ from
what ends up getting standardized could be a problem. So I would hope
that we've given this some serious thought and come up with a plan and
policy for how to do it. I have ideas[4], but I certainly hope other
people have given this a lot more thought already.
----
1. Calling the previous extension mechanism an API is giving it too much
credit. "Stuff we didn't prevent from being used, that was useful for
making addons"?
2. I would call it crazy and stupid move if I didn't happen to agree
with it. Or if I was ok with calling myself crazy and stupid. And I'm
not crazy.
3. Uh... I've never really thought about it before, but who paints their
floors? I wouldn't think that'd wear well. I guess "Let's not Wet
Swiffer ourselves into a corner!" doesn't have quite the same ring.
4. This scenario is easier than general web compatibility, because (1)
we have an upgrade mechanism for addons, and (2) we're starting out so
have the opportunity to set things up to make changes easier. For
example, if you had to explicitly import specific extension points, it
would be much easier to know what is being used and what might break; no
need to bend over backwards to do feature detection. Also, some of the
arguments against versioning JS or DOM don't apply here, so we might
consider that in some form. We even have a signing mechanism, so we
could control access on a per-API basis if it would help.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
