On 25/06/13 12:15 PM, Mounir Lamouri wrote:
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.
I waffled on this but if you think "[Ww]eb APIs" is more clear, I'll go
with that.
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.
My hope was to get something in place for APIs and then build up to
other web-exposed "things" like CSS, etc.
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.
Done. Although note that others have expressed concern about the
"intent to ship"->"shipping" situation.
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
Fixed.
"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.
I changed it to "at least two other browser engines ship (regardless if
it's behind a flag or not in their equivalent of beta or release) -- a
compatible implementation of this API ". How's that? I don't want to
see us basing our decision to ship on another engine's use of their
nightly equivalent for experimentation (whether this happens right now
or not). Am I worried for no reason?
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.
That was the situation I was thinking of :)
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...
The way you read it obviously not something we want to do. What if we
dropped the "ecosystem-"? I can't see how we can allow ourselves to
ship hardware-specific APIs that don't work everywhere without an
exception like this. Are there situations where we would ship such an
API on desktop if there's very little chance of the required hardware
existing 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.
That was my attempt to not limit our ability to innovate without other
engines. I'm open to alternative phrasings.
Declaring Intent
API review
Implementation
Shipping
I think some clarifications are needed in those areas.
I changed the section headers to:
Declaring Intent to Implement
API review
Implementation
Intent to Ship and Shipping
How's that?
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.
I added some wording to clarify that the email should do _both_. I was
also not assuming affiliation would necessarily define the "API review
team".
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.
I admit I didn't think much about "dev-platform" coming to a consensus.
I guess I'd like major disputes to be handled on a case-by-case basis
and not have to define what should be done in the infinite discussion
situations. Maybe we should just be more forthcoming as reviewers or
module owners about something we wouldn't want to ship and thus save
potential implementors' time.
It would be great to have a list of required information for intent
emails. A template could be quite helpful.
Yep, Blink has a template and I intend to create one once we have a bit
more agreement on the proposed policy.
2. how do we keep track of progress towards standardization for
in-development APIs?
Isn't that part of the developer's responsibilities?
I was thinking more of some sort of dashboard like chromestatus.com
4. should we enforce this by putting all WebIDL files into a new
module?
Why?
It had been brought up as an idea elsewhere but if no one thinks it's
necessary, it won't happen :)
Thanks very much for the feedback,
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
