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
case it will make sense to add a Foo2 and support both, either forever
or for a while. But that's really a separate, though related, question.
Also, when you un-suffix when the API is standardized, you can keep the
old Foo02 as an alias for Foo, so anyone building code on the
pre-release Foo02 continues to work. While semantically the same as
leaving a mozFoo, it has more sense to it - Foo is a shorthand for
Foo02. You don't have to leave it - there are arguments on both sides
(leaving it encourages people to use the "pre-release" version - but by
definition, it's the same API, so that's not really a problem.)
>In case of features like WebRTC where it's almost certain that
>breakage will occur, if we ship without prefix, we’ll be no worse off
>than shipping with prefix. Breakage occurs either way and experience
>shows that a prefix is worthless as a signal of API stability. So even
>in cases like WebRTC, it makes sense to bet for the case where
>breakage doesn't need to occur (i.e. the spec doesn’t end up changing
>after all).
--
Randell Jesup, Mozilla Corp
remove .news for personal responses
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
