Henri wrote:
>It seems to me that we won't get agreement on policy about not
>shipping experimental features on the release channel. However, it
>seems to me that we could be able to agree not to ship moz-prefixed
>APIs on the release channel.
>
>So I adjust my policy proposal to:
>Therefore, I propose that we adopt the following policy:
> 1) APIs that are shipped on the release channel shall be shipped
>without a prefix.
> 2) If we ship APIs that don't have specs already, we'll write specs.
>
>I think a policy not to ship moz-prefixed APIs on the release channel
>would give enough flexibility to ship experimental features (without
>prefix) when market pressure so requires but would generally have
>positive consequences that would lead to less breakage for features
>that have reached the release channel.
>In the case of features where we don't know if the general design will
>be accepted as a cross-browser standard, shipping without prefix makes
>things better in the case our design gets accepted. With prefixes, we
>get breakage either way, so with prefixes we are always betting wrong.
>If our design doesn't get accepted, the standard can simply choose a
>differently-named API entry point. After all, the space of possible
>identifiers is countably infinite.
tl;dr - prefixing is bad. It's not good even before Release. API
version suffixing may be better.
Sure, if when standardized people add another parameter, you can change
the feature from Foo to Foo2 (or Bar, or Qwerty). But usually we've
chosen a "good" name for the feature (I hope), and people along the way
have learned that is the name of he feature, and so no one wants to
change it to Bar. If we use Foo2, then people get the "right" name, and
the API forevermore has the artifact that the API changed along the way.
(This may sound familiar from COM and other such APIs...)
Concrete example: Opera implemented an idea - navigator.getUserMedia().
This led to a standardization effort, which is standardizing
getUserMedia(). Great. But (no surprise) we all decided the API needed
to change (though I think for a time Opera resisted this; not for
long). So it's not compatible with Opera's getUserMedia() - but we
didn't change the name to Bar; everyone *knew* it was getUserMedia().
Everyone else implemented it with prefixes (even when still the same as
Opera's). webkitGetUserMedia() has changed API a couple of times and
likely will at least once more, because we're STILL arguing over whether
it should be fully asynchronous or partially async, or take a
placeholder input stream, etc. This is not a change we can really
avoid; we need it for important cases or we have to pevert an API
elsewhere. If this next iteration is adopted, then everyone will
unprefix to getUserMedia() - and clash with Opera's implementation.
A mess, to be sure. But Opera not prefixing didn't help things. I'll
note that vendor prefixing (moz/webkit) didn't help much either, except
that it avoided polluting the desired final symbol.
I'll note that Chrome did learn some from this, and for PeerConnection
they didn't vendor-prefix, they API-suffixed - PeerConnection01/02/etc.
When they un-prefixed they removed the API version (and changed to
RTCPeerConnection, because of arguments in the WG about namespacing in
JS - ask Anant).
One huge advantage to API versioning - they could change more than
once. Yes, conceptually there's nothing different about changing Foo to
Bar to Qwe compared to Foo01 to Foo02 to Foo - but people understand the
relationship of the second much better and more intuitively. (You *can*
remove the final change to Foo, and one can argue that ALL APIs should
have version suffixes, or after the first change - but at least for
simpler APIs one hopes they won't change again. Bigger ones like
PeerConnection may change, and then...)
Another advantage is that if during the process (including before
Release channel) two or more browsers implement the same proposed API
(closely enough) they can use the same version suffix. These wouldn't
be speced by the WG ("the Aug 3rd draft is Foo02"), but would be added
as needed by the browsers. If they don't, at least they won't clash and
people experimenting with the APIs will be able to use one or both, as
they prefer.
Coming back to prefixing - I dislike prefixing; but mostly because it
means only one change of API is allowed without people having to try to
sniff the version of the implementation. This *includes* prefixing
before going to Release channel! API suffixing seems a much better
solution, semantically equivalent to Foo to Bar to Final but easier to
understand (and to recognize when someone is using a pre-release API, if
we avoid shipping suffixed versions - though if we want to rev an API,
which will happen on occasion, suffixes are an option, though it may make
more sense in those cases to use some internal versioning or other way
to change/add functionality without breaking old users. Perhaps in some
ca
