On 21/06/13 21:45, Andrew Overholt wrote: > I'd appreciate your review feedback. Thanks.
Thank you for putting this together. I am going to quote some parts of the document to give some context to my comments. > Note that at this time, we are specifically focusing on new JS APIs > and not on CSS, WebGL, WebRTC, or other existing features/properties. I think the "JS APIs" here is unclear. I think saying "Web APIs" would be more appropriate, assuming this is what you meant. Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We should definitely not make this policy retro-apply so existing features should not be affected but if someone wants to add a new CSS property, it is not clear why this shouldn't go trough this process. > 1. Is the API standardized or on its way to being so? > 2. Declaration of intent > 3. API review > 4. Implementation > 5. Shipping I think 2) should be "Declaration of intent to implement" and we should add an item between 4) and 5) named "Declaration of intent to ship". Those two distinct items are important I believe. > 2. at least two other browser vendors ship a compatible > implementation of this API I will join Henri: "browser vendors" should be "browser engines" and "ship" is too restrictive. If a feature is implemented and available in some version (even behind a flag) with a clear intent to ship it at some point, this should be enough for us to follow. > 3. at least one other browser vendor ships -- or publicly states > their intention to ship -- a compatible implementation of this API > and there is a specification that is no longer at risk of significant > changes, on track to become a standard with an relevant standards > body, and acceptable to a number of applicable parties Actually, with this point, point 2) sounds barely useful. The only situation when we could have 3) applying but not 2) would be if two engines implement a feature that has no specification. > 2. ecosystem- and hardware-specific APIs that are not standard or of > interest to the broader web at that time (or ever) may be shipped in > a way to limit their harm of the broader web (ex. only on a device > or only in specific builds with clear disclaimers about applicability > of exposed APIs). An example of this is the FM Radio API for Firefox > OS. When I read this, I read "It is okay to have Mozilla ship a phone with proprietary APIs". That means that we are okay with Mozilla creating the situation Apple created on Mobile, a situation that Mozilla has been criticising a lot. Shipping proprietary APIs on a specific device is harming the broader Web if that device happens to be one of the most used device out there... > 3. APIs solving use cases which no browser vendor shipping an engine > other Gecko is interested in at that time. In cases such as this, > Mozilla will solicit feedback from as many relevant parties as > possible, begin the standardization process with a relevant standards > body, and create a test suite as part of the standards process. An > example of this is the Push Notifications API. I am not a big fan of that exception. Given how fast paced the Web is nowadays, we could easily put a lot of APIs in that category. Actually, if we ask other vendors what they think about most Firefox OS APIs, we will very likely get no answer. Does that mean that those APIs are good to go? > Declaring Intent > API review > Implementation > Shipping I think some clarifications are needed in those areas. First of all, we should define two kind of "Declaration of intent", one for implementation and one for shipping. Implementation could be a Public Service Announcement aimed to know if anyone strongly objects. In other words, if I want to implement feature foo, I would have to start a thread, explain what I want to do, in which context (platforms) and ask if anyone objects. Then should come the intent to ship email that would be more formal. In my opinion, the reviewing part should be simplified. Intent emails should be reviewed by "dev-platform", not a "API review team". In other words, any one should be able to express its opinion and opinions will be listened based on their technical value, not based on affiliation. The code review should follow the usual rules and the IDL should have a super-review as the current Mozilla rules requires it. Adding a commit hook to dom/webidl/ to make sure that commits have a sr+ would be great to enforce that rule even though it wouldn't prevent all problems. The issue with having "dev-platform" finding a consensus with intent emails is that we might end up in a infinite debate. In that case, we should use the module system and have the module owner(s) of the associated area of code make the decision. If the module owner(s) can't take this decision, we could go upward and ask Brendan to make it. It would be great to have a list of required information for intent emails. A template could be quite helpful. > 1. should we have a joint mailing list with Blink for intent to > implement/ship? What would be the benefits? Some mozillians are following the blink mailing list to keep track of the API being implemented and shipped by Blink. For people worried about being flooded, it is easy to write a filtering rule to discard non-intent emails. This said, having a public Mozilla/Google or Gecko/Blink channel to discuss cross-browsers issues might be interesting. > 2. how do we keep track of progress towards standardization for > in-development APIs? Isn't that part of the developer's responsibilities? > 3. how do levels of API exposure for Firefox OS apps (certified, > packaged, etc.) fit into this policy? I think Firefox OS should get an explicit rule about what Jonas and I have been trying to do: APIs should have broader exposition when they are more mature. That means that highly experimental and quickly designed APIs should stay as certified-only until we believe that the API is good enough to be used by a restricted set of third-party (privileged applications). Moving to any-app situation should be the last step before pushing the API out of the app-only world. > 4. should we enforce this by putting all WebIDL files into a new > module? Why? -- Mounir _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
