On 07/26/2017 10:45 PM, Andrew Swan wrote:
On Wed, Jul 26, 2017 at 4:27 PM, Steve Fink <sf...@mozilla.com
<mailto:sf...@mozilla.com>> wrote:
This thread worries me greatly. Somebody tell me we have a plan
and policy around this already. Please?
We might, but I'm not sure what "this" you're concerned about.
Whether API names should be prefixed? Or whether we should expose
things at all that are unique to gecko/firefox to extensions? There
are a whole bunch of things that get considered when new extension
APIs are proposed including safety, maintainability, performance, and
yes, cross-browser compatibility.
"this" == exposing Gecko-specific functionality, or rather, what
Gecko-specific functionality to expose and how to expose it in general.
With emphasis on the how. The prefixing decision (answer: no) and
do-it-at-all decision (answer: yes) are part of that.
Unfortunately, there isn't anything written that explains actual
criteria in detail (its on our radar but somewhere behind a long list
of engineering tasks on the short-term priority list).
And I guess the parenthetical clause is what worries me. The people
churning through that workload should be churning through that workload,
and it's fine that they aren't spending time and mental space on the
theoretical concerns of future compatibility issues or addon developer
relations. But this is kind of a big deal for Mozilla strategically, so
I would expect someone else to be working on the strategic plan before
we reach the foot-shooting point.
Hopefully, that someone would be in close contact with the engineers
doing the work, since they have the best context and familiarity with
large parts of the problem space, and hence their opinions deserve a lot
of weight. As long as the consultation doesn't get in the way of getting
stuff done. There's a ton of weight on you people's shoulders, and we
don't want to add more.
One person can do both strategy and tactics (or implementation) just
fine, but it's usually not a good idea to do them at the same time.
Different mindset, different tradeoffs.
My individual opinion is that something being unique to gecko or
firefox should not disqualify it from being exposed to extensions.
The webcompat analogy doesn't really work here, the principle that the
web should be open and interoperable demands rigor in what gets
exposed to content. But a browser extension isn't a web page, it is
part of the browser itself, and different browsers are inherently ...
different. They have different features, different user interfaces,
etc. The fact that browser extensions are built with web technology
and that they modify or extend the very thing that displays web
content obscures this distinction, but it does make a big difference.
I agree. But it isn't completely different from webcompat, either. We
have used up much of developer's tolerance for breaking changes, so we
really want to try hard to minimize changes that are going to break
addons. (And minimize the pain of such breakage -- if we have a
mechanism allowing us to easily identify the addons that will be
affected, and provide a warning and documentation of the change in
advance, we can probably get away with quite a bit.)
Anyway, containers is a good example of something that we've exposed
to extensions that isn't likely to be supported in other browsers any
time soon. Nevertheless, we need to design APIs in a way that doesn't
compromise on the other areas mentioned above: maintainability,
safety, performance. And, to the extent we can, we should design APIs
that could be adopted by other browsers if they choose to.
Sure, and in my mind, that's the sort of tactical decisionmaking that
*should* be done in the context of implementation. Which is different
from the overall strategy of prefixing / opt-in imports / signing /
versioning.
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.
There are certainly outraged addon authors out there but for what its
worth, we're also already getting a good amount of positive feedback
from both addon authors and users.
Sorry, don't take my ranting to imply that I'm somehow unhappy with the
work you people are doing. To the contrary, it all seems to be going
stunningly well, which is much to the credit of your team.
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.
I think that's basically the attitude of most of the people working on
webextensions. To be pedantic, the threshold is higher than "If we
can". I mean, we *could* expose Components to webextensions but of
course that would bring us right back to all the problems we're
working on putting behind us.
No disagreement there.
Again, documenting more formally specifically what it means for an
extension API to be safe, maintainable, performant, etc. is something
we know is needed. Hopefully when we come up for air after 57 we can
work on this (and complementary things like webextensions experiments).
Yeah, that's not really what I'm talking about. In a way, that's the
hard part. But it's unavoidable, and it's happening in practice, and I'm
sure there'll be a lag in formalization while things are taking shape.
That's probably a good thing, since it'll require experience to flesh
these things out.
But that's about individual APIs. I want high-level answers to the
simultaneous questions "How are we going to expose sufficient
functionality to provide extension authors with what they need?" and
"How are we going to avoid shooting ourselves in the foot when we get
further down the road?" The sort of things you read in high-level
strategy documents that set down the goals, direction, and approach to
known obstacles. (Not that I necessarily want such a document; they're
boring and make for dull reading, and I'm always suspicious as to
whether anyone's paying attention to them. But I want the thinking
behind it.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
