Fair enough, but then your message subject misled me.

--
Warning: May contain traces of nuts.

On 2012-11-12 6:01 AM, Henri Sivonen wrote:

I agree.  Prefixing in practice is really just a way to make us feel
better about breaking something which we have shipped before, and that's
bad for web developers.  But this is sort of an orthogonal discussion.

I'm not sure if that call can be made easily in all cases.  There might
be parts of a given spec that we don't want to implement because they
are bad ideas, and while we try to fix them in the spec, doing so is not
always possible.  Our position on such types of issues might change
because web developers may start depending on those features to an
extent where we have to implement them, and I'm afraid that with the
policy you're proposing, such cases may prevent us from shipping a
feature to the release channel unprefixed for an extended period of time.

Cheers,
Ehsan

Mostly because a) they're big, b) they involve complex and
still-being-defined underlying protocols coming from the IETF, like
signaling (JSEP (being defined for WebRTC/rtcweb) and SDP), c) as we get
initial implementations up, gain experience with them and start using
the more complex cases, we're realizing some earlier assumptions were
flawed (the recent getUserMedia() API change to return a (blocked)
stream immediately before permissions are granted (or not) is an
example, to speed call-answer time in apps).

Telecom/Skype-like/etc service providers very much want to get access to
these and to deal with the flux.  These generally are NOT typical web
developers; these tend to be people with a lot of telecom experience
formerly working with SIP or similar applications (sometimes built on
Flash using RTFMP (the author of which is part of the effort)).

Small demo apps may break (or be dropped to a deprecated interface) and
not be updated.  This is quite true.

Understood, though those are quite different issues from this.  And
we've pointedly warned app devs we'd be removing old APIs even if we
support them for a while, and have done so (or rather Chrome has).

See above.  We're not at the tweak phase, we're finding actual flaws in
functionality as we try to write more complex applications (though it is
firming up; we may be past the major changes phase with the last
getUserMedia change, but I wouldn't put heavy money on it.).

FYI, I may not have been clear: Chrome has dropped the API version
suffix, but they're still prefixed.  This means an app can distinguish
between us, but to track finer changes it will need to UA sniff or
feature-detect in some manner (like recently when we implemented
mediastream.stop() and forced apps to use it properly, or when we added
basic constraint support).  

I *liked* the version suffix idea because if thing change, you know *and
can key off it temporarily* instead of getting vague "it stopped
working" reports and being forced to only support old or new (or fiddle
with unplanned detection code).  Also, as we converge, we can use the
same suffix as Chrome if we have the same API (more applicable to
smaller changes than all of WebRTC, but still useful).

See above.  I'm afraid those aren't viable options.  We are in close
contact with most people using these APIs, and they generally know the
APIs are in flux, and that they must track changes.  It is a somewhat
different community used to interacting with standards bodies (and
dealing with standards like SIP where every device implements a
different subset of the HUGE number of RFCs (plus device-specific
quirks)).  Our current state is actually far more "standard" than VoIP
people are used to.

Not so theoretical in this case, though it's not guaranteed.  With two
platforms (so far) implementing and progressing unevenly, one must
either prefix/suffix or use feature queries (as we don't want UA sniffing!)

They *are* going away, and we've had no compunction about killing them
and updating the demo/test pages so far.  Once we "pref on" (as google
is), the bar will be higher, but we will continue to track the spec and
will not support deprecated APIs for a long period (if at all).  We even
have API check code on the WebRTC landing page to determine what API
your browser has and warn you if it's old or incompatible with the
current tests.

Well, the biggest reason is that these aren't random web devs, these
devs are much more involved in the mailing lists and used to
standards-body tracking (lots of IETF/VoIP people, and people used to
dealing with IETF drafts changing during development).  We have lots of
contact with them via the various mailing lists and are using G+,
webrtc.org and our test landing page on github to inform them and move
them forward.  Some demos will be abandoned, but that's ok.

The biggest problem here (aluded to above) is that the API is broad
enough and progress by the two sides uneven enough that we haven't ever
had a converged API we could both support yet.  We are moving towards
that (at least demos of interop calls), but even those will be done
partially by polyfill and maybe some wireline protocol adapters
temporarily.  (Getting ICE (NAT traversal) to be compatible, for example.)

Polyfills here reduce the pain and breakage, but may not fully eliminate
it, and that's probably ok for this audience.

...

read more »

On 06/11/12 13:31, Henri Sivonen wrote:

For that, we will need some tools to know if we are building for Release
(and let say Beta) where the feature should be hidden by default, with
opposition to Aurora, Nightly or custom builds where the feature should
be enabled by default.
Also, how would that work for things that doesn't have
Nightly/Aurora/Beta/Release channels?

IMO, this is currently the main reason why prefixing is a pain: we want
to allow devs to try the feature easily and Nightly/Aurora is there for
that but having to disable the feature as soon as it reaches Beta is
just too much maintenance.

Cheers,
--
Mounir

We already have ways of doing that (usually based off of
MOZ_UPDATE_CHANNEL). We could introduce some more elegant/robust
solution - we already do it enough that a better solution would
probably be nice. See
https://bugzilla.mozilla.org/show_bug.cgi?id=803276#c4.

What do you mean?

Gavin

On 14/11/12 19:27, Gavin Sharp wrote:

MOZ_UPDATE_CHANNEL contains a string and AFAIK, we can't use C
preprocessor to compare strings so it might not be enough.

I was thinking of things like Firefox OS that might not have such
concept. We should make sure that they do not end up doing the wrong thing.

--
Mounir

The common solution is to check MOZ_UPDATE_CHANNEL in the Makefile to
adjust defined variables, see e.g.:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/Makefile...
http://mxr.mozilla.org/mozilla-central/source/browser/installer/Makef...

Ah, right - I think that's where a better solution like the ones I
alluded to in my previous comment would help. I'm not overly fond of
the various MOZ_UPDATE_CHANNEL (ab)uses :)

Gavin

I think it isn’t orthogonal. I think having a way that makes us feel
better about breaking stuff is something we shouldn’t have. I expect
we’d make better decisions about breakage if we didn’t have an excuse
that allows us to delude ourselves about the fact that breakage is
being caused.

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 that Gecko developers know to be unbaked
without compelling market pressure to ship them in an unbaked state, I
would expect this policy to have the consequence of not shipping such
unbaked features on the release channel. (For this to be easy to
accomplish, there should probably be a C preprocessor define that is
different for Release (and maybe Beta) compared to Aurora, Nightly and
self-built.

In the case of features that are technically in good shape but just
haven't had a standards setting group put their mark on them, I think
this would have the positive effect of discouraging bikeshedding. For
example, if we had shipped the full-screen API without prefix, I
expect we could have avoided the total bikeshed of changing the case
of the letter ‘S’ in “fullScreen”. (It’s so confusing that even MDN
contradicts itself. I’ll fix after sending this email.)

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.

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).

So let’s get a C preprocessor define for that. It shouldn’t be a big
deal to conjure a suitable one into existence.

Surely Firefox OS has *some* distinction between release builds and
development builds?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

On 2012-11-27 3:49 AM, Henri Sivonen wrote:

I totally agree.  But note that this is basically rephrasing "prefixing
sucks" in a better way.  :-)

Where do partial implementations of specs fall here?  Can we ship
something unprefixed without implementing the full spec?

And what will happen to the original name that we've shipped?  Would we
remove support for it at some point?

Hmm, Web IDL bindings already support exposing names hidden behind a
pref, so we can technically do without the C preprocessor macro that
you're proposing, at least for the stuff that we can use Web IDL
bindings for (and that's what everybody is using for the new APIs,
right?  ;-)

I think we should prefer prefs over build-time flags, since they always
have the chance of surprising us when we uplift something from Beta to
Release.

Cheers,
Ehsan

It would be up to the implementor and reviewer to make the guess
whether the partial feature is unlikely to require later breaking
changes and unlikely to preclude later implementing the full feature.
If the guess is that the part already implemented is ready to be used
by Web developers and shipping only that part is unlikely to induce
Web content that would be broken by implementing the rest of the spec
later, then the partial feature can be shipped to the release channel
(without prefix).

If there is a reason to believe that implementing just a part would
result in Web content that would break with a later implementation of
the rest, it would be better to wait until the rest is ready, but the
policy I outlined above is silent, really.

Maybe we’d guess wrong some time, but that would be better than always
guessing wrong in the sense of always guessing that things will be
named mozFoo when they end up being named foo. :-)

Sure.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

On 2012-11-30 12:16 PM, Henri Sivonen wrote:

Makes a lot of sense to me.  Thanks for the explanation Henri.  I'm in
full support of this proposal.

Ehsan

In yesterday’s platform meeting, it turned out that I had
misunderstood Randell’s position on prefixing WebRTC.

Even though in general, it might be bad for a policy to have seemingly
ad hoc exceptions, I think making an exception for WebRTC is
reasonable, because:
 * WebRTC is already in the implementation pipeline and the policy was
meant for new features and not for abruptly removing existing
prefixes, so it seems reasonable to stretch the notion of “existing
feature” to an in-the-pipeline feature in the case of a huge feature
like WebRTC where making changes right now might be too disruptive.
 * It appears that there’s some kind of commitment made in the WG
involved as in the case of WebGL.
 * WebRTC is a uniquely huge feature (or set of features) and it needs
special rollout (unusual iteration after release).
 * Even if WebRTC and WebGL were excluded, I think it would be a big
win to stop prefixing other APIs that are introduced.

Also, a clarification was asked about whether the policy was proposed
to apply to new features only or also to existing features. (I
intended it to apply to new features.)

Therefore, I propose that we adopt the following policy:
 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the
release channel shall be shipped without a prefix.
 2) If APIs that don’t already have specs are shipped, we’ll get specs written.

(For clarity, the above formulation does not require WebGL or WebRTC
to have prefixes.)

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

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.)

--
Randell Jesup, Mozilla Corp
remove .news for personal responses

2012/12/5 Henri Sivonen <hsivo...@iki.fi>

Thanks. To be clear and to conclude this on a positive note, the context of
our WG commitment in the case of WebGL is that WebGL prefixes are
reasonably kept under control:
 - Only WebGL extensions can have suffixes, not core WebGL functionality;
 - The WebGL API is designed so that you can't accidentally rely on an
extension (you have to explicitly call getExtension before you can use any
non-core functionality).
 - There is a definite process to drop WebGL extension suffixes, so we can
drop suffixes on WebGL extensions that reach "community approved" status,
which actually happens in practice, typically after a few months or
real-world testing.

A couple draft WebGL extensions are overdue now for promoting to community
status, but other than that, the process is not too bad.

Benoit

Are you OK with the latest policy proposal I made or do you intend to
make a counter-proposal with suffixing?

Latest for reference:
 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the
release channel shall be shipped without a prefix.
 2) If APIs that don’t already have specs are shipped, we’ll get specs written.

(This policy implies nothing about what exactly WebRTC or WebGL do.
They are simply outside the scope of the proposed policy.)

Better yet, adding more arguments to a method does not require
changing its name at all.

Even if WebRTC ends up using version suffixes, let’s not do that for
APIs in general. Experience suggests that it has been possible to
introduce APIs (e.g. APIs introduced by IE of old, canvas 2D or APIs
introduced by “HTML5”) without either prefixing or suffixing, so
making suffixing a rule seems like an overkill. I think in the usual
case (i.e. the non-WebRTC, non-WebGL case), it would make sense to see
how well we’ll do without either prefixes or suffixes. If we end up
doing fine, there is no need to add complexity.

Also, version suffixes can re-introduce the problem that, like vendor
prefixes, they might make us think it’s more OK to still bikeshed
things and introduce just one more version.

I don’t think it’s a separate question. With version suffixing, there
is a very real risk that removing old versions will break too much
content and so old versions stick around forever. In that case, the
same kind of considerations as those stated in
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and
http://robert.ocallahan.org/2008/01/http-equiv_22.html apply.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

I'm ok with it, but I think it may be insufficient to avoid problems.
One could argue if we're going to try to push everyone to move off the
current prefixing, let's do it once.  We're not likely to try again
soon, let alone succeed.  Is it better than today?  Yes, arguably.  Does
it solve the fundamental problems?  Only partly, and really only if
everyone follows suit.  Are Google, MS and Apple (and Opera) on-board
with this?

Quite true (and I mentioned elsewhere); I was writing quickly.  Please
re-read as "some API change that's not backwards compatible".

Both reasonable arguments.  Versioning might be best reserved for
more-complex-than-average APIs and ones where people want to do
cross-browser experimentation (pre-release).  

The second argument might be minimized or avoided by not shipping
suffixed APIs for the simpler ones.  Though I'm unsure how large a
problem this would be, compared to the current issues with prefixing.

Yes.  It's a classic "stick with something forever" or "support the old
thing (virtually) forever" or "break the old thing (now or sometime
'soon')".  This certainly has minuses, but never improving does too.
And introducing it under a totally different name (instead of
Foo2) doesn't change anything.

--
Randell Jesup, Mozilla Corp
remove ".news" for personal email

Great!

It turned out to be harder to get agreement on the part whose purpose
was to avoid problems: the part about not shipping experimental stuff
on the release channel.

If WebGL and WebRTC don’t want to be pushed now, I’d rather stop
vendor prefixing for everything else and let WebGL and WebRTC to come
round at their own pace than see this proposal sink because of WebGL
or WebRTC concerns. (WebGL and WebRTC living in their own worlds isn’t
quite safe, though, because they can leak. For example, we have WebGL
to blame for making the Web platform dependent on little-endian
hardware. Or maybe the real blame should go to TC39 for not giving
WebGL something better in a timely fashion.)

If we require everyone to move in unison, we’ll never make progress.
Someone needs to make the first move and others will follow if the CSS
situation is any indicator. Previous discussions make me expect Opera
and Google to be the most likely vendors to follow us soon if we stop
shipping vendor prefixes.

Considering that versioning has been an anti-pattern on the Web in
general[1], I think we should wait and see how versioning works for
WebRTC before doing it more broadly. (My general expectation is that
it’s bad to introduce APIs in such more-complex-than-average chunks
that the need for versioning arises.)

[1] HTML tried to version itself but browsers ingest all versions
using the same code. Likewise for SVG. On the other hand, XML tried to
version itself but coupled versioning with such a disastrous error
handling policy that their 1.1 launch flopped. JS versioning is
virtually unused on the Web (as opposed to Firefox-internal code). CSS
has been wisely designed as versionless from the processing point of
view.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

On 11/12/12 06:40, Henri Sivonen wrote:

Name mangling is a poor solution. Perhaps we could come up with an API
for exposing experimental features?

  enableExperimentalFeature(feature, version)

Anthony

To go back to an earlier part of this thread: If you expose something
on the release channel to Web authors, you are de facto releasing the
feature for Web authors to bake into their sites/apps and risking it
getting stuck in the sense that breaking changes cause a bad end user
experience of sites/apps breaking. A moz prefix does not change that.
Having to call enableExperimentalFeature() won’t change that. Writing
documentation that says the feature is experimental won’t change that.

As with version suffixing, there is a very real risk that removing old
versions will break too much content and so old versions stick around
forever. In that case, the
same kind of considerations as those stated in
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and
http://robert.ocallahan.org/2008/01/http-equiv_22.html apply.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/