On 2013-06-26 12:08 PM, Andrew Overholt wrote:
"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?
If another engine has an implementation behind a flag in a prerelease
channel, I don't see why we can't coordinate the possible changes that
they're considering with them. I don't think that's going to be a huge
concern.
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?
I think what Mounir is worrying about is the reverse situation where
people code against our APIs without knowing that they're not available
on other devices. Mounir, do you have the same concern about certified
Firefox OS APIs? What about privileged APIs?
To answer your question, Andrew, I think it would be a good idea to ship
our APIs consistently on all platforms where the required hardware is
available.
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.
We should definitely try to prevent people from spending time
implementing something that we are never going to ship. But I think
Mounir's point is good here. Experience has shown that getting
consensus on dev-platform is, well, not very easy. Therefore I think
the escalation path that Mounir is proposing is a good idea.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
