"during the first 12 months of development of new user-facing products, APIs that have not yet been embraced by other vendors or thoroughly discussed by standards bodies may be shipped only as a part of this product, thus clearly indicating their lack of standardization and limiting any market share they may attain"
I think this needs some refinements. In B2G, we haven't even been able to approach standardizing a few of the APIs because we've been too swamped with actually getting stuff shipped. This despite having worked on shipping for something like two years. I think we need to base any timelines here on shipping, not starting of development. Additionally, there are lots of pieces that are new and not part of the normal web. We definitely are going to standardizing them all, but we have to do it in an order that makes sense. Additionally, it's unclear if the above is saying that unless we can get something passing the rules in the "Standardization" section within 12 months, that we should remove it from later versions of the product? I don't think such a requirement would ever be implemented. I don't have a lot of great answers here. The best thing I can think of is something like: "For new products, APIs that have not yet been embraced by other vendors or thoroughly discussed by standards bodies may be shipped only as a part of this product. Standardization must however start within X months after shipping initial version of the product". In B2G we additionally have the extra fun of not being able to even start standardizing a lot of the APIs because they have dependencies on the runtime and security model, which is still being worked on. But I think it's clear that there can be dependencies that needs to be resolved in the right order. I also think we should explicitly define a policy for what to do with the APIs before we are able to standardize them. I.e. should we ship them prefixed, under a window.mozilla namespace, or using a "normal" name. I tend to disagree with Henri here and think that we should stay out of the way from whatever name we think the final standard should have. At least in cases where we expect to need to change the API a lot as we improve it (as is the case with most B2G APIs). I don't see the need for the second exception. "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." I can't think of any APIs that fall into this category. FM Radio should absolutely be standardized. Our current implementation definitely falls under the "new product" exception, but eventually we should fix it up and get it standardized. / Jonas On Fri, Jun 21, 2013 at 10:45 PM, Andrew Overholt <[email protected]> wrote: > Back in November, Henri Sivonen started a thread here entitled "Proposal: > Not shipping prefixed APIs on the release channel" [1]. The policy of not > shipping moz-prefixed APIs in releases was accepted AFAICT. > > I've incorporated that policy into a broader one regarding web API exposure. > I'd like to see us document this so everyone can easily find our stance in > this area, similar to how they can with Blink [2]. > > I've put a draft here: > > https://wiki.mozilla.org/User:Overholt/APIExposurePolicy > > I'd appreciate your review feedback. Thanks. > > [1] > https://groups.google.com/d/msg/mozilla.dev.platform/34JfwyEh5e4/emA1LAoVEVQJ > > [2] > http://www.chromium.org/blink#new-features > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
