Blink, PNaCl, And Standards

When the Blink fork was announced, it came with an admirable commitment to good citizenship when adding new Web-exposed features. Unfortunately, Google has recently announced that they will expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs --- to all Web pages, a move which clearly runs counter to Blink's commitments.

PNaCl is an execution framework that lets Web developers compile code in various languages using LLVM-based compilers to LLVM "bitcode", which is then served to clients (i.e. Chrome) which compile it down into native code. To be useful, code needs APIs to interact with the outside world (e.g. graphics APIs), so Google created the "Pepper" APIs for NaCl/PNaCl applications to use. Let's see how PNaCl and Pepper stack up against the Blink principles:

• In practice, we strive to ensure that the features we ship by default have open standards.

  PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. Other vendors wishing to support PNaCl or Pepper would have to adopt or reverse-engineer this code.

• Factors that decrease compatibility risk (in rough order of importance):

  • Other vendors shipping compatible implementations
  • A mature specification in the relevant standards body
  • Positive signals from other browser vendors
  • A small API footprint

  PNaCl and Pepper satisfy none of these. In particular, there are no positive signals from other browser vendors; in fact all the signals I've detected have been hostile.

• The following tiers are good rules of thumb to know that the feature is on the right track (ordered by increasing risk to compatibility and therefore decreasing order of desirability):

  • Two other browser engines already ship roughly interoperable implementations in stable or experimental channels. In this situation, the feature is already a de facto standard. If a de jure standard does not yet exist, we should help create one.
  • One other browser engine ships a roughly interoperable implementation in a stable or experimental channel, we believe the feature to be stable, and we’ve consulted with the appropriate standards body.
  • The appropriate standards body considers the feature ready for implementation. For example, the W3C issuing a Call for Implementations or publishing a Candidate Recommendation of the feature would meet this guideline.
  • The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.

  Again, PNaCl and Pepper satisfy none of these.

• In extremely rare cases, we may enable a feature by default before the feature's compatibility risk is as low as we'd like. In such cases, we will meet the following requirements:

  • We will propose an editor’s draft (or equivalent) to the relevant standards group.
  • We will discuss the feature publicly with implementers of other browser engines.

  Further, we will take on an active commitment to shepherd the feature through the standards process, accepting the burden of possible API changes.

  Again, none of this is happening for PNaCl and Pepper.

• [Regarding the Blink "Feature Dashboard"] We associate each value with a shade of red or green, corresponding to how the value reflects our web citizenship. For example, “opposition from another browser vendor” is red and “a similar implementation in another browser” is green. Viewed in aggregate, these colors provide a quick snapshot of the project’s overall web citizenship.

  PNaCl and Pepper aren't on that dashboard, but if they were, they'd be a very, very bright shade of red.

The disconnect is alarming. Unfortunately it appears Blink's principles only apply to Blink, not Chrome as a whole. I'm sad, because this seriously undermines the value of the Blink team's good intentions; a Google team that doesn't want to be a good Web citizen can probably find a way to be "not Blink" and run roughshod over the Blink team's good work :-(.

Taiwan Travelogue

In Taipei we had probably the best Gecko work week I've ever been to. It was also, for me, the most draining. Apart from getting the regular Gecko teams together for work and fun, we also got to meet many of the new Mozilla developers in Taipei. This was very helpful and a lot of fun. However, as a senior Mozilla figure I felt a lot of responsibility to educate and generally facilitate the interactions of all our teams, 24/7, and since I'm not naturally gregarious, my social skills were plain worn out by the end of the week. It was exacerbated by the sheer number of people, and the cultural and language barriers. I also have to struggle against the urge to strut before Chinese women. Fortunately I have considerable experience dealing with these issues, otherwise I probably would have imploded.

That aside, it was all very very good. The food was amazing. The breakfast at the Grand Hyatt is the best hotel breakfast I've ever seen, by some distance. The Chinese banquet dinners were over-the-top great (bar the shark's fin --- gah). The mango dessert in the Taipei 101 basement food court --- mango chunks, shaved ice, condensed milk, brown sugar syrup, and mango ice cream --- was so good I had it twice. The extracurricular activities included visiting the National Palace museum, board games at night, and two trips into the hills. The day after I arrived, Sunday morning, I completed my first ever organized running event, a 10km trail run in the hills on the north side of the city, with a few other Mozilla staff. It was hot and humid, but the field was pretty weak and mostly walked up the steep bits, which worked to my advantage since I have long legs and walking fast uphill is my specialty, so I came in 18th out of 88 male-over-40 finishers. On Saturday morning, just before we left, a group of Mozilla people went for a hike to and beyond Elephant Mountain. That was lots of fun.

During the week, I led two sessions not related to specific technical issues: one was on "Mozilla culture" --- what we do, why we do it, how we should change it, specifically targeted at people relatively new to Mozilla, especially those from companies with very different cultures. Part of that was about code review, and stimulated another session specifically about code review, and how to do it better. I have videos of those sessions, and once I've scrubbed them to remove one or two unfortunate comments I'll put them online :-).

It turns out that currently the only place you can buy official Mozilla merchandise is the Taiwan office's online store. Anticipating this, I brought a half-empty suitcase and placed the biggest order the store had ever seen. Now I have a stockpile of gifts for friends and family that should last a while :-). We desperately need an international Mozilla gear store, though.

Since I'd seen most of the good Air New Zealand May movies earlier this month, the plane movie selection was a bit random...

• The Last Stand: Schwarznegger vehicle, so I had low expectations, but they were exceeded. Not a great movie, but not a bad one.
• The Assassins: Borderline incomprehensible Chinese movie. I missed being able to pause the movie and ask my wife what on earth is going on.
• Taken 2: Such a bad movie. Utterly boring and predictable, none of it makes any sense at all, and embraces a number of common movie failures: classic combination of the bad guys being both supremely brilliant and completely stupid; classic assassin-idolization main character who kills people without feeling but is also a really great guy; classic divorced couple who are so right for each other it's incomprehensible why they got divorced in the first place. Avoid.
• Remembering 1942: Really really good. Got mixed reviews, but I think it's a great movie. It's a litany of human suffering, set in the Chinese province of Henan, trapped in the vice of war and famine. Watching movies like this periodically helps me keep a sense of perspective.
• Ripper Street (series): Victorian police procedural. I had low expectations, but was actually quite impressed. Conveys a real sense of the times --- and they were interesting times indeed.

It was a great decision to have the work week in Taiwan, and I hope we get back there soon.

Travel

Last week I was in California. It was my first time in the Mozilla SF office --- lovely view of the Bay from the roof. I always enjoy the free snacks and I'm always glad we don't have them in Auckland. I spent quality time with some of the people I know and love at Mozilla, and that's always exciting.

On Wednesday and Thursday I was at Half Moon Bay doing LEAD training. It was fun, but thinking about "soft skills" for two days straight is quite draining for me; my social skills are learned, not innate.

This cohort is different from previous cohorts --- most members are relatively new to Mozilla; of our cohort, Vlad and I have been at Mozilla the longest, by far. This gives me the honor and duty of representing the Mozilla old guard. I feel the power of the narrative that has me in the "crusty old engineer, harping about the old days and resisting change" role ... and I do my best to reject it :-).

One of the results of LEAD so far is that I perceive my relationships with other Mozilla staff to be warmer and stronger than they perceive them, on average. I suspect this may be related to the difficulty of maintaining deep relationships with remote employees I see a few times a year at best. I'm still trying to figure that out.

Plane movies:

• Gangster Squad: Genre flick. OK.
• Zero Dark Thirty: Pretty good. Not exactly entertaining, but interesting.
• Live And Let Die: Some kind of cross between a Bond movie, a blaxploitation flick, and the Dukes Of Hazzard. Odd.
• The Town: Genre flick. Slightly better than average.
• I, Anna: Sort of noir-ish psychological thriller. OK.
• Les Miserable: The movie of the musical. Pretty good. I need to read the book sometime.

Interestingly, Air New Zealand lets you see what movies they're showing on their routes. This Web interface is a pretty faithful mockup of the actual in-seat interface (which is pretty bad ... it would be great to be able to see more than one movie title at a time).

On Friday I leave for Taiwan for a week at the Mozilla office, a "Web rendering" work week. This should be even more fun than last week.

The Direct Route

Over time I've become increasingly impressed with the broad applicability of Matthew 18:15-17:

If your brother or sister sins, go and point out their fault, just between the two of you. If they listen to you, you have won them over. But if they will not listen, take one or two others along, so that ‘every matter may be established by the testimony of two or three witnesses.’ If they still refuse to listen, tell it to the church; and if they refuse to listen even to the church, treat them as you would a pagan or a tax collector.

The first step is often difficult but crucial. The path of least resistance can be to go behind your antagonist's back --- to your friends, or their friends, or their manager. I've seen all kinds of negative consequences from following that path --- hurt, distrust, unnecessary escalation, confusion and fear. I feel my integrity depends on people knowing that whatever I say about them to others, they will not be surprised by because they've already heard it from me.

This applies in the other direction too, when people complain about third parties to me. If the third party is unaware of the issue, I don't want to know --- go away and talk to them first.

There are rare exceptions, usually involving time-critical emergencies or complex secrecy requirements.

Web Audio Progress

Our Web Audio implementation is making great progress. This is mainly due to the efforts of Ehsan Akhgari, who is, astoundingly, cranking out one or two features per day. Paul Adenot and I are spending hours every day just reviewing his code. I think this is partly due to Ehsan and I laying down some pretty good infrastructure at the outset.

Our current goal is to have a basically complete implementation for Firefox 24, which branches from trunk in about eight weeks. There are a few things we need to do to get there:

• Complete the feature set. At this point that mainly means adding all the node types that aren't implemented yet: MediaStreamAudioDestinationNode, MediaStreamAudioSourceNode, MediaElementAudioSourceNode, ConvolverNode, OscillatorNode, and WaveShaperNode. The first three are all related and shouldn't be too hard since we designed Web Audio from the start to share infrastructure with MediaStreams (which are already integrated into media elements) --- internally, a Web Audio node is just a special kind of MediaStream. We still need to implement HRTF and soundfield panning modes for PannerNode. We need to implement OfflineAudioContext. For some of the audio algorithms that aren't very well specified, we're borrowing code from Blink. This is suboptimal but there's ongoing discussion about what level of detail we should specify the audio algorithms at.
• Work on latency. Right now audio output has pretty bad latency, especially on Android, FirefoxOS and Windows; the biggest problems are intrinsic issues with the platform APIs we're using. On older versions of Android and Windows XP it may be a lost cause, because good APIs simply aren't available. For Windows Vista and up we're writing a new audio output backend using WASAPI. On FirefoxOS we may rip out the Android code we're using and replace it with PulseAudio. There is additional work to do to better integrate the MediaStreamGraph (that drives MediaStream and AudioNode processing) with our libcubeb audio backends for lower latency and better tracking of the audio clock. This latency work is desperately needed for WebRTC as well as Web Audio.
• Work on throughput. Right now we're focusing on having a good clean design and functional correctness. For example, all communication and synchronization with the MediaStreamGraph real-time processing thread is asynchronous, using message passing. Updates to Web Audio and MediaStream graphs are batched so all changes performed by a script happen atomically on the real-time thread. But we haven't done any profiling, tuning, or optimization of the actual processing code. In particular we'll clearly need SIMD implementations of basic audio primitives such as mixing to get near-maximum performance, especially on mobile.
• Test and fix bugs, needless to say.

Contributors welcome! The Web Audio bug (779297) has a lot of dependencies to choose from :-).

One interesting issue that Jean-Marc Valin brought up recently is the prospect of a loudness war on the Web. Some areas, such as Sony's Playstation products and some broadcast TV regions, are trying to mitigate the loudness war by standardizing acceptable dB levels for all content. It might be a good idea to do this on the Web too, and have browsers automatically limit the volume of content that exceeds those levels. We're still thinking about whether and how this should be done, and talking about it on public-audio.