FWIW, I share Steve's broad concerns here. Mozilla's track record on extension APIs has had many dead-ends and changes of direction. Now that we're wiping the slate clean, it would be good to not repeat history.
Nick On Fri, Jul 28, 2017 at 3:02 AM, Steve Fink <sf...@mozilla.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
