On Thu, Jul 27, 2017 at 7:14 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> 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. > I'm surprised it hasn't been mentioned here, but there is a process in place for new APIs. This is my understanding of how it works: 1. API is prototyped as a WebExtension experiment. There's a fair amount of documentation on how to do this [1], including API guidelines [2]. This would be a probably good place for people to add rules of thumb, like roc's point about free-form JSON being a bad idea. 2. File a bug for the API and mark it [design-decision-needed]. The API will be discussed first in the bug, then in the community meeting, and possibly brought to the WebExtensions advisory group [3] if there are any concerns. 3. The API will be either accepted or rejected. Quite a few do get rejected, so it's not a rubber stamp. I think it's common for step 1 to be omitted, in which case someone from the WebExtension team has to implement the API. But the intention is to allow add-on developers to be able to propose an API without having to wait for us to implement it. If people have concerns, the best thing to do is to be a part of this process. It's an open discussion, and I think that it would benefit from more platform people participating--especially people who have experience with web standards. There also has been a lot of discussion of this process itself on dev-addons, which is where most of this stuff gets talked about. -Bill [1] https://webextensions-experiments.readthedocs.io/en/latest/ [2] https://webextensions-experiments.readthedocs.io/en/latest/new.html [3] https://wiki.mozilla.org/WebExtensions/AdvisoryGroup > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
