I was about a week into my m-c hg-git conversion* when gps blogged about faster hg-git.

I was about two weeks into the initial conversion when I tried the latest upstream hg-git, with gps' patches. That conversion finished in less than a day, while the initial conversion was still chugging along on a different core. However, the git shas differed from our existing pre-cvs conversion repositories. This was due to different behavior when faced with a bogus email address.

Once I backed out the corresponding email munging commits, and landed Ehsan's timezone fix for a separate issue that halted the conversion process, we're now back to a converted m-c with the same shas.

At this point I killed the still-running initial conversion.

I'm still working on automating the cvs prepending and pulling in other repos/branches, but this is a good sanity-check point.

* Note, I had pulled both mozilla-central and mozilla-b2g18 into the same working directory as a proof-of-concept workflow test before converting. In hindsight this was a terrible decision, as it more than doubled the estimated conversion time.

Earlier in April (4-7 April to be exact) I was in Istanbul to speak [slides] at Free Software & Linux Days at Bilgi University, the main FOSS conference in Turkey. I spoke their previously in 2010. This time I got great support from Mozilla Rep Selim Sumlu and we had a stand to show off some Firefox OS demo devices. I also had the opportunity to speak on a panel at a brief afternoon session at Bogazici University. One of the main reasons of the trip was community building, as Mozilla Turkey has been suffering in that regard.

I won’t go into detail, instead pointing you to Selim’s report of the event. A few observations though:

• The power of the Firefox OS draw was evident because our table was consistently busy despite our lack of swag.
• Everyone was telling me that while Open Source was prevalent in Turkey, it has not really caught the imagination of people beyond a core community. I see opportunity there.
• Happy to have met Emin Mastizada who is leading a budding new community in Azerbaijan.

With Selim and Emin.

Mozilla Turkey is small, and we are looking for people to join and help out in a number of areas. These include leadership, community building, marketing, programming, social media, and more. Our hope is to grow and become a strong community to help Mozilla with their mission to promote openness, innovation and opportunity on the Web. Contact Selim or I to find out more.

Hope to see you again soon Istanbul. Here are more pictures from my visit.

If any step in your process to customize and deploy Firefox involves unpacking and repacking omni.ja[r], you're probably doing it wrong. Any modifications you need to make to Firefox, whether it be changing the default profiles, changing the default preferences or even overriding specific files can be done WITHOUT repackaging omni.ja[r].

If you really think you have a use case for unpacking the omni.ja[r], let me know and I'll try to prove you wrong.

Now you know...

Almost three weeks ago, I flew to Cluj (the hearth of Trasilvania) to be part of the first Mozilla Romanian Community meet-up. It was a tough decision to go, as I’m trying to lower my participation in community events and keep focus on new projects.  But Ioana (who organized and planned the meet-up)  finally convinced me – telling me that we’d try to make the meet-up different and even more, offering me the task of advancing the meetup’s agenda.
And, in the end, I’m very happy that I finally decided to go.  It was a very productive and constructive event and it made me leave Romania feeling inspired, motivated and optimistic.

Below I’m going to highlight the things that most impressed me there:

• diversity of community participants:  Mozilla Romania is a community network with participants of different ages, individuals doing their own projects, Mozilla staff, companies such as Softvision, non-profit organizations such as Ceata or participants in Student Labs as ROSEDU.
• more than 50% were people I never met before (except maybe via twitter or mailing list).
• I met Alper, 16 years old, who has been organizing for a while Webmaker and Programming events in his town. He shared with us how hard is to be a teen who wants to do stuff and does not have much support from local organizations because of his age. This brought into conversation the difficulty for under 18 Mozillians to participate in the broader Mozilla Project (e.g. accepted as Mozilla Reps).
• Support and build local social initiatives: during the session where we sorted out topics, there was a good number of social initiatives, or… how to start working with organizations that already help people acquire new technical skills. Valentin is already part of the Digital Kids program, Alper is trying to do something with organizations in his city, Dan shared his experiences with the YearUP program in Mountain View, I shared some of the experiences trying to ignite a Hive Barcelona Community. There are lots of opportunities to work through this in a future.
• Mobile – a strong testing community - In Romania, the testing community has been growing for a long while and especially, in important tech. hubs such as Ia?i and Cluj. There were not so many conversations about FirefoxOS or WebApps, but more  about testing or how to get more people involved into FirefoxOS project through testing.
• Community Building and Tools – those were two main sessions with  lot of participation and interest. One of the questions was: “How do we make Mozilla.ro community a strong community support network?”. There are individual contributors who want to do things and help advance Mozilla’s mission but don’t know where to go and whom to ask when they may need it. One of the approaches to this was, apart of “just do it” – to take advantage of Mozillians.org social network (a better use of tags, group and skills categories) so you can find your “go to person” or your mentor. There have been other topics such as making events more visible or turning the local get involved page more attractive.
• Participants from major Academic and Tech hubs in Romania: participants came from cities like Bucharest, Cluj, Iasi and Constanta, Hunedoara, Carei. And of course expat Romanians from Barcelona, Berlin and Mountain View.
• We had the meet-up (and planning meet-up) in two amazing co-working spaces in Cluj: ClujHub and Cluj Co-work!

 

Overall, the meet-up was really productive, I think. Ioana and Alex will come with more details about what’s next, after we finish documenting it. We started it with an interactive plenary around: challenges to contribute in a community project, the importance of individual, decentralized contributions and demand of permission vs. good communication. The goal of the meet-up was to see how to work together more efficiently and avoiding unnecessary conflicts.

I think that we achieved a big part of this goal. Of course, there is more to do, and most importantly, lead as individuals, document and then share back next year.

What I took with me from all this experience is the optimism that communities in Mozilla can be seen differently, not just a resource. Community is a group of like-minded people and organizations who work for a common goal. Yes, some communities produce resources: as documentation, word of mouth marketing, tools, products and others. But one of the things there are often ignored are the signals that a community produces.

The question here is how to help the community produce useful and meaningful signals (not noise) – signals that can sometimes drive the project into new directions and even contribute to decision making processes. Probably the answer is: a different approach to community building – meet-ups are opportunities, not events where suffocate people with top-down agendas and topics. Agendas should be for empowering and motivating, for listening and then building.

There are tons of positive and interesting signals I received from the Mozro meet-up and I’d probably write more abut later. Until then, thanks to Dan Gherman, Ioana, Brian King and Alex for helping with the pre-planning!

 

RSS Ticker has been an alternative to Web-based feed readers since 2006, displaying feed updates directly in users' browsers. It hasn't seen significant change in a while, but some of the internal Firefox code used by RSS Ticker has changed enough that in order for it to remain functional in Firefox 22, its entire architecture would have to change. That's a lot of work.

I didn't want to abandon RSS Ticker's users (especially with the shutdown of Google Reader imminent, already leaving one less feed reading option), but I also couldn't dedicate the time to completely rewrite the add-on and keep all of its features. So here's what I've done:

RSS Ticker has been completely rewritten. This has given me the opportunity to use the knowledge I've gained in the last seven years of programming to improve the overall design of the ticker and to restructure the code to play nicely with the new Firefox APIs.

What hasn't changed? RSS Ticker will still scroll your feeds in your browser. You can still choose to put it at the top or bottom of your Firefox window. You can still exclude specific feeds. You can mark as read, mark feeds as read, open in tabs, open all in tabs, etc. You can temporarily disable the ticker. You can change the ticker speed, smoothness, and direction. You can hide the ticker automatically when it's empty.

What has changed? In order to continue supporting RSS Ticker, I've had to drop a number of features. Here are some things you can no longer do with RSS Ticker:

• Manually refresh the feeds.
• Specify how often the feeds should refresh.
• Randomize the order of the ticker items
• Limit the number of items per feed
• Display items that have already been read
• Show unread items in bold
• Manually limit the width of ticker items
• Customize the context menu

I know some of you liked and used these features. I'm sorry I had to remove them, but it was the choice between removing them or abandoning the add-on altogether.

A few features haven't been removed, but they have been changed (a.k.a. "improved"):

1. All of the remaining options (six of them, down from a total of 37) are displayed inline in RSS Ticker's section of the Add-ons Manager.

2. If you want to temporarily disable the ticker, just uncheck it in the View > Toolbars menu.

3. To remove a feed from the ticker (but not from your bookmarks), right-click on it in the Bookmarks Manager and uncheck "Show in RSS Ticker."

This new version will be available in a couple of weeks after some more testing, but if you'd like to test it early, leave your e-mail address in a comment or ping me at cfinke@gmail.com and I'll send you a copy.

This chart plots per-month sums of total time of jobs in Mozilla's automation in days. The line running through it is a best fit linear regression.

The raw data is available.

Update: Please note that this post describes the current implementation in SpiderMonkey. The final ES6 specification will require generator functions to have a ‘*’ token as in function* nat() { … }. The flatten() function from the last example could use yield* to delegate instead of a nested loop.

JavaScript comes with most of the little functional tools you need to work on finite sequences that are usually implemented using Arrays. Array.prototype includes a number of methods like map() and filter() that apply a given function to all items of the Array and return the resulting new Array.

[1, 2, 3].map(x => x + 1); // result: [2, 3, 4];

These tools however are not a good fit for infinite sequences as they always consume the whole sequence at once to return a new one. Implementing infinite sequences by yourself means you would have to come up with your own API that clients need to adhere to. You often would keep state variables whose values need to be maintained for the duration of the computation process.

Generators to the rescue

Using ES6 generators implementing the infinite sequence of all natural numbers turns out to be a trivial task. We even have language support to iterate over them.

function nat() { var i = 1; while (true) { yield i++; } } var it = nat(); console.log(it.next(), it.next(), it.next()); // prints 1 2 3

Now that we have a first infinite set we need a couple of functions that help us working with, combining, and building new sequences.

Mapping

Let us start with map() - a function at the very heart of functional programming. It builds a new sequence by applying a function to all elements of a given sequence.

function map(it, f) { for (var x of it) { yield f(x); } }

Using the generator implementation of map() we can now easily write a function called squares() that represents the set of squares of all natural numbers (1², 2², 3², …, n²).

function squares() { return map(nat(), x => x * x); } var it = squares(); console.log(it.next(), it.next(), it.next()); // prints 1 4 9

Using for…in instead of for…of works fine but using of has a neat advantage in that it properly iterates Arrays as well. If you want to map values of a finite sequence you can just do that.

var it = map([1, 2, 3], x => x * x); console.log(it.next(), it.next(), it.next()); // prints 1 4 9 Filtering

Another common task is filtering specific values from a sequence. Our custom implementation of filter() takes an iterator and a predicate - the returned sequence will consist of all items of the original one for which the predicate holds.

function filter(it, f) { for (var x of it) { if (f(x)) { yield x; } } }

We can now use filter() to create the set of all even natural numbers.

function even() { return filter(nat(), x => x % 2 === 0); } var it = even(); console.log(it.next(), it.next(), it.next()); // prints 2 4 6

A common derivation from filter() is filterNot() that simply negates the given predicate. We can use that to implement even() as well.

function filterNot(it, f) { return filter(it, x => !f(x)); } function even() { return filterNot(nat(), x => x % 2); } Mersenne primes

Suppose we were to implement a sequence that represents all Mersenne prime numbers. Mersenne primes are defined as prime numbers of the form Mn = 2n - 1, that is the set of all numbers of the given form that have no positive divisors other than 1 and themselves. The set of Mersenne primes is assumed to be infinite though this remains unproven, yet.

Let us first define some helper functions. range(from, to) and forall() are common helpers in functional programming languages. range() returns the set of natural numbers in a given range. forall() returns whether the given predicate holds for all items in the sequence and should therefore only be used for finite sequences.

function range(lo, hi) { while (lo <= hi) { yield lo++; } } function forall(it, f) { for (var x of it) { if (!f(x)) { return false; } } return true; }

mersenneNumbers() is the set of all numbers of the form Mn = 2n - 1. isPrime() is a very simple and naive (and slow) primality checker that returns whether the given candidate is divisible by any of the numbers in the range of [2, candidate - 1]. We will use isPrime() as a filter to remove all non-prime numbers from mersenneNumbers().

function mersenneNumbers() { return map(nat(), x => Math.pow(2, x + 1) - 1); } function mersennePrimes() { function isPrime(n) { return forall(range(2, n - 1), x => n % x); } return filter(mersenneNumbers(), isPrime); } var it = mersennePrimes(); console.log(it.next(), it.next(), it.next()); // prints 3 7 31 Flattening

As a last example we will implement a function that flattens nested sequences.

function flatten(it) { for (var x of it) { if (Object.prototype.toString.call(x) === "[object Generator]" || Array.isArray(x)) { for (var y of flatten(x)) { yield y; } } else { yield x; } } }

Note that using for…of comes in handy again as we can use it to iterate over Arrays and generators. Using flatten() we can now do:

flatten([1, [2, 3], [[4], [5]]]); // result: [1, 2, 3, 4, 5]

Combining flatten() and map() to flatMap() we can implement another very common function that flattens the result of applying a given function to all items of a sequence. Let us use it to re-build the set of all natural numbers from the set of all even natural numbers.

function flatMap(it, f) { return flatten(map(it, f)); } var it = flatMap(even(), x => [x - 1, x]); console.log(it.next(), it.next(), it.next()); // prints 1 2 3 Generators are powerful

It is quite obvious that studying ES6 generators really repays. They are a very powerful language construct and I personally cannot wait until they are available in V8/Node.js as well. They will be in the toolbox of every professional JavaScript developer soon and I am sure we can count on the community to come up with lots of great uses and libraries.

Quick update on recent progress.

Vsync from a thread

Following the first experimental vsync implementation on Windows (using GetVBlankInfo which is non-blocking and synchronous), I’ve been experimenting with another implementation which vlad suggested: Run a thread which uses WaitForVBlank (blocking until next vblank) and post the timing event to the main thread.

The conclusions are here. In a nutshell: WaitForVBlank works nicely (when it works), but also blocks the main thread, and while some circumvention is possible (using sleep), it’s still far from ideal. Thanks goes (yet again) to Bas for helpful tips on Windows APIs and integration into the Layer manager.

Since OMTC might integrate WaitForVBlank into its pipe more naturally, it was decided to land the original approach - which is very lite and reasonably working, especially when using the main/single monitor - and reconsider the other approach with OMTC.

Expect vsync on Windows nightlies soon.

New tab previews hurts tab animation

That’s bug 843853. I decided to put it on hold for now, as it appears that not enough resources can be directed towards it. It would have been nice, however, to see a more practical list of priorities - which more carefully takes resources into account. Hopefully, we’ll have such list soon.

Timer filter removal regressions

Bug 590422 (remove averaging filter for timers - which probably hurts timing more than it helps) landed some time ago, but still rears its head. The most recent is lost frames while decoding video.

Apparently what happens is that the filter removal also hurts average timer intervals when high resolution timers are not enabled, and video decoding uses timers without making sure they’re in “high-res mode”. The fix was quick everyone’s happy.

This also brought a new discussion about automatically enabling high-res timers according to some heuristics on the requested timeouts (and possibly also the request source). While it sounds useful, the main argument against it is that high-res timers have slightly higher power draw, and that it could be abused by content pages which use setTimeout(0) while what they actually want is “soon enough”, and therefore get much more frequent callbacks than required.

This discussion is still ongoing, you’re welcome to contribute more factors to consider.

Tabstrip animation project goals

There has been some discussion on refining the project goals, to make them both useful from a user perspective (rather than mostly synthetic bar) and also reasonably achievable. We feel comfortable with this definition, which, in a nutshell, is:

• Have Smooth enough (50FPS or more) animation during the last part of the animation.
• Make sure this happens on some concrete cases we care about (such that newtab open, close a tab and get into a gmail tab, etc).

What’s next?

• Land Windows vsync.

• Get a clear priorities list for newtab slowdown.

• Implement a regression test which could measure our discrete tab animation goals (tab animation telemetry is useful, but has lower resolution than we’d like), and give each a score. Still not sure if as a talos test, but right now talos appears to be the proper place for it.

the following changes have been pushed to bugzilla.mozilla.org:

• [866807] [sentry] “use of uninitialized values” warnings in quicksearch
• [866805] [sentry] “Unicode character 0xfffe is illegal” warnings
• [866806] [sentry] Lost connection to MySQL server during query
• [867399] [sentry] “use of uninitialized values” warnings in quicksearch
• [858909] [Oracle] When running checksetup.pl for the first time using Oracle as DB server, you get an “uninitialized value” warning
• [848635] Old queries based on tags are no longer listed in the page footer by default when upgrading from 4.0 or older to 4.2
• [867207] make the “Internet Public Policy” custom form the default for bugs, with a link to the standard bug entry form
• [867520] guided bug entry doesn’t honour the default bug format
• [867177] Backport bug 745533to bmo/4.2 to add index to audit_log table
• [848382] The background of attachment fields is dark gray in the Mozilla theme
• [865686] Add new Bugzilla product under “Other” called “Developer Ecosystem”
• [866248] Add DATE type for custom fields
• [859118] Bug.search called with no arguments returns all visible bugs, ignoring max_search_results and search_allow_no_criteria
• [212471] Tabular reports do not link bug counts involving the empty resolution correctly
• [825886] When moving bugs from one product to another, I should be able to keep a security bug private across groups that I’m not a member of
• [868915] guided bug entry’s guided_products.js throws ISE when a product is missing

Filed under: bmo, mozilla

After read this article about the first Mobile Device Library in Montreal and I decide write this small post because I think that we can do two things about:

1. Put FirefoxOS phones in this libraries
2. Offer this service in the Mozilla spaces for free but only for FirefoxOS phones.

Is important to be when developers are.

Classé dans:Statut Tagged: english, FirefoxOS, mobile, Mozilla

Mozilla is unique. Unique in it's structure, in the way we organize ourselves, in the way we work, in the way we interact with others and in the work we're doing.

Mozilla's stated mission is "to promote openness, innovation & opportunity on the Web". That's it. Simple. And so incredibly important. Pretty much every other organization which is working "on the Web" is beholden to shareholders and their legitimate desire to increase their return on investment. Not Mozilla.

Mozilla impacts the world through our products, the communities we build around these products and the influence we gain through the combination of users and products. And we increasingly build communities around our values – communities which take our values and embed them into their own work.

In both areas we have the unique opportunity to significantly increase scale and scope and thus multiplying our impact on the world – in turn creating a better Web and thus a better world.

I find myself in the amazing position to poke around the organization and help us think "magnitudes bigger/better". The one question which keeps me up at night (and incredibly excited) is: How can we increase our impact on the world by factor 10? Factor 50? Factor 100?

I've got a bunch of ideas – and know that I have huge blind spots. Opportunities I don't see. Things I haven't thought about. Ideas which are bubbling beneath the surface.

I would love to hear from you: What would you do to increase Mozilla's impact in the world?

Leave a comment on this post or send me an email at p @ mozilla.com. And let's invent the future together.

This is a post for the Mozilla Webmaker MOOC called #teachtheweb. You can get involved here!

There’s a tendency that we all at various times either demonstrate or resist. In ascertaining the value of other people’s thoughts, innovations or opinions we ask for evidence of impact. But when it comes to our own thoughts, innovations or opinions, we believe evidence to be unnecessary because it’s self-evident.

So it is with learning new skills. Those without the skills ask questions about the value of obtaining them (“where’s the evidence?”), while to those with the skills it just seems obvious. And then there’s the perennial question about ‘transferability’. Just what counts as something being a ‘transferable skill’ anyway?*

To me, innovation comes at the overlap of two or more circles of a Venn diagram. It stands to reason, therefore, that the more circles there are on your Venn diagram, the more chances there are for overlap.

Learning a new language is like making your Venn diagram of skills three-dimensional. And by ‘a new language’ I mean things like HTML, JavaScript and Python just as much as French, Spanish and Chinese. These languages are new conceptual tools, new ways of looking at the world. Learning to play a musical instrument and understand mathematical abstraction/notation also falls into this camp, I reckon.

As a Pragmatist, I like the description William James gives of the world as a “bloomin’ buzzin’ confusion”. There is no way that we can have an objective or neutral view of the world, so the more lenses we can use to view it, the better.**

I’m (at best) currently an average wrangler of HTML and CSS, and a beginner with JavaScript. But the computational thinking I’ve developed through learning these from a reasonably young age (and before that messing about with a BBC Micro) have stood me in good stead for seeing the world differently.***

Why do we need to see the world differently? Well, because the problems that we face as a society are increasingly complex. We need people who speak many languages – including those of machines – to be able to solve them. We don’t need a society of pure programmers any more than we need a society of pure linguists or musicians. What we do need are people who know a bit of each.

That’s why I think learning a little code is important.

* I kind of discussed this in this blog post.

** I love the HTML Hunting in the World Around You challenge in P2PU’s School of Webcraft as an example of this.

*** I’m currently re-learning French through Duolingo.

TL;DR

We can now browse our albums, artists and songs (no playlists yet) and play them

Details:

GNOME Music application development is reaching the end of phase one (out of three).

This phase consists of:

• Set basic infrastructure (done)
• Implement Grilo Querying (done) 
• Implement Albums View (done)
• Implement Songs View (done)
• Implement Artist View (done)
• Implement Playback support (done)
• Clean up and port to Glade (in progress)

If you feel like hacking along please don’t mind to help out:

• Get the code from https://git.gnome.org/browse/gnome-music
• Report bugs https://bugzilla.gnome.org/browse.cgi?product=gnome-music
• Join the development on IRC #gnome-music on irc.gimp.net
• To check out our vague plan visit: https://live.gnome.org/Music

Thanks for everybody who has been helping out.

Thanks to Guillaume Quintard and the potential SoC students for posting to glade and fixing some of the UI issues. Also Vadim Rutkovsky started working on some unittests (which kicks ass).

And now to leave you with some screenshots…

 

 

I've been coding a lot and didn't realize how much.

If you have ever used the application cache you will probably be familiar with how easy it is to break offline functionality and how difficult it is to work out why things are broken. With a large offline web app finding the source of problems can be an almost insurmountable task.

I guess that what I am saying is that the application cache is a douchebag. I completely understand that if there is an error in your application's manifest you probably don't want your users to be confronted with a bunch of error messages but something needs to be done.

Because displaying a bunch of errors about a broken cache manifest is probably undesirable we have decided to create a developer tool that lets you know if you have a problem with your manifest. The main problem we have is that the Toolbox is already becoming crowded and we are just getting started.

Firefox Developer Tools Toolbox (we have space issues)

In order to avoid cluttering the Toolbox we have used the Firefox Command Line. The command line is a place where we can add as many tools as we like without cluttering the interface. To open the Developer Toolbar press or select "Developer Toolbar" from the web developer menu.

The appcache commands are available in Firefox Nightly

To list available appcache commands type "help appcache" in the developer toolbar.

Output from the help appcache command

The currently available appcache commands are:

appcache clear

Clear all appcache entries.

appcache list [searchterm] # list all appcache entries containing an optional search term Output from the appcache list command appcache viewentry

Show the about:cache-entry page for the current cache entry.

Note: appcache viewentry will not give you any information until bug 861866 is fixed.

appcache validate [URI]

This is by far the most useful of the appcache commands. If a URI is specified then the cache manifest for that page will be validated. As many of you know, there are a lot of things that could invalidate a manifest but this command will uncover most of them.

Output from the appcache validate command

If you find any situations where an application cache is invalid and our tool does not pick up the problem then please let us know. In fact, if you have an idea for a new appcache command then please tell us.

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.

This week I’ve been:

• Helping kids hack their school websites at Maker Faire (using X-Ray Goggles) with my Mozilla / Make Things Do Stuff colleagues.
• Hosting the weekly Web Literacy standard call.
• Talking to people via Skype and in person about integrating with the Open Badges Infrastructure (OBI). I had my closest meeting yet – just 5 miles away! Also, excitingly, it looks like CoderDojo might be badgifying their belts!
• Starting planning an Open Badges workshop focusing on assessment at the Mozilla London office in June. I then had to postpone/cancel it as I’ve been invited to an EU summit on the same date.
• Sharing the first draft of Mozilla’s Web Literacy standard with the Webmaker community on the weekly call.
• Participating in the first week of the Mozilla #teachtheweb MOOC.
• Talking with Vinay Gupta about an idea about a ‘Firecloud’ evolution of the Firefox web browser that we’re considering submitting to the Mozilla Labs Hatchery.
• Setting a date in July for an Open Badges workshop at the University of Hull.
• Helping judge a Technology Strategy Board funding round including some work around Open Badges.
• Presenting and answering questions at an Open Badges briefing session for Leicester schools, organised by Josie Fraser. My slides are here.

Next week it’s Bank Holiday (woo!) then I’m in London on Tuesday night/Wednesday morning for a meeting with Lord Jim Knight. Then on Friday I’m in Salford to talk to the BBC about Open Badges for their CPD programme(s).

For the last week I’ve been using a Geeksphone Keon as my only phone. There’s been no cheating here, I don’t have a backup Android phone and I’ve not taken to carrying around a tablet everywhere I go (though its use has increased at home slightly…) On the whole, the experience has been positive. Considering how entrenched I was in Android applications and Google services, it’s been surprisingly easy to make the switch. I would recommend anyone getting the Geeksphones to build their own OS images though, the shipped images are pretty poor.

Among the many things I missed (Spotify is number 1 in that list btw), I could have done with a countdown timer. Contrary to what the interfaces of most Android timer apps would have you believe, it’s not rocket-science to write a usable timer, so I figured this would be a decent entry-point into writing mobile web applications. For the most part, this would just be your average web-page, but I did want it to feel ‘native’, so I started looking at the new building blocks site that documents the FirefoxOS shared resources. I had elaborate plans for tabs and headers and such, but turns out, all I really needed was the button style. The site doesn’t make hugely clear that you’ll actually need to check out the shared resources yourself, which can be found on GitHub.

Writing the app was easy, except perhaps for getting things to align vertically (for which I used the nested div/”display: table-cell; vertical-alignment: middle;” trick), but it was a bit harder when I wanted to use some of the new APIs. In particular, I wanted the timer to continue to work when the app is closed, and I wanted it to alert you only when you aren’t looking at it. This required use of the Alarm API, the Notifications API and the Page Visibility API.

The page visibility API was pretty self-explanatory, and I had no issues using it. I use this to know when the app is put into the background (which, handily, always happens before closing it. I think). When the page gets hidden, I use the Alarm API to set an alarm for when the current timer is due to elapse to wake up the application. I found this particularly hard to use as the documentation is very poor (though it turns out the code you need is quite short). Finally, I use the Notifications API to spawn a notification if the app isn’t visible when the timer elapses. Notifications were reasonably easy to use, but I’ve yet to figure out how to map clicking on a notification to raising my application – I don’t really know what I’m doing wrong here, any help is appreciated! Update: Thanks to Thanos Lefteris in the comments below, this now works – activating the notification will bring you back to the app.

The last hurdle was deploying to an actual device, as opposed to the simulator. Apparently the simulator has a deploy-to-device feature, but this wasn’t appearing for me and it would mean having to fire up my Linux VM (I have my reasons) anyway, as there are currently no Windows drivers for the Geeksphone devices available. I obviously don’t want to submit this to the Firefox marketplace yet, as I’ve barely tested it. I have my own VPS, so ideally I could just upload the app to a directory, add a meta tag in the header and try it out on the device, but unfortunately it isn’t as easy as that.

Getting it to work well as a web-page is a good first step, and to do that you’ll want to add a meta viewport tag. Getting the app to install itself from that page was easy to do, but difficult to find out about. I think the process for this is harder than it needs to be and quite poorly documented, but basically, you want this in your app:

if (navigator.mozApps) {   var request = navigator.mozApps.getSelf();   request.onsuccess = function() {     if (!this.result) {       request = navigator.mozApps.install(location.protocol + "//" + location.host + location.pathname + "manifest.webapp");       request.onerror = function() {         console.log("Install failed: " + this.error.name);       };     }   }; }

And you want all paths in your manifest and appcache manifest to be absolute (you can assume the host, but you can’t have paths relative to the directory the files are in). This last part makes deployment very awkward, assuming you don’t want to have all of your app assets in the root directory of your server and you don’t want to setup vhosts for every app. You also need to make sure your server has the webapp mimetype setup. Mozilla has a great online app validation tool that can help you debug problems in this process.

And we’re done! (Ctrl+Shift+M to toggle responsive design mode in Firefox)

Visiting the page will offer to install the app for you on a device that supports app installation (i.e. a Firefox OS device). Not bad for a night’s work! Feel free to laugh at my n00b source and tell me how terrible it is in the comments

This morning, Mozilla and OTOY made an announcement:

Mozilla and OTOY deliver the power of native PC applications to the Web, unveil next generation JavaScript video codec for movies and cloud gaming

What this means:

ORBX.js, a downloadable HD codec written in JS and WebGL. The advantages are many. On the good-for-the-open-web side: no encumbered-format burden on web browsers, they are just IP-blind runtimes. Technical wins start with the ability to evolve and improve the codec over time, instead of taking ten years to specify and burn it into silicon.

After these come more wins: 25% better compression than H.264 for competitive quality, adaptive bit-rate while streaming, integer and (soon) floating point coding, better color depth, better intra-frame coding, a more parallelizable design — the list goes on.

The GPU cloud has your back. Think of the amazing 3D games that we have on PCs, consoles, and handheld devices thanks to the GPU. Now think of hundreds of GPUs in the cloud, working for you to over-detail, ray/path-trace in realtime, encode video, do arbitrary (GPGPU) computation.

Or consider high-powered tools from Autodesk, Adobe, and others for 3D modeling and rendering:

Native apps from any popular OS, in the GPU cloud and on your browser. Yes, both: this is not just remote desktop tech, or X11 reborn via JS. Many local/remote hybrid computation schemes are at hand today, e.g. a game can do near-field computing in the browser on a beefy client while offloading lower LOD work to the GPU cloud.

OTOY’s CEO Jules Urbach demo’ed an entire Mac OS X desktop running in a cloud VM sandbox, rendering via ORBX.js to Firefox, but also showed a Windows homescreen running on his Mac — and the system tray, start menu, and app icons were all local HTML5/JS (apps were a mix ranging from mostly local to fully remoted, each in its own cloud sandbox).

Valve’s Steam was one such app:

Watermarking, not DRM. This could be huge. OTOY’s GPU cloud approach enables individually watermarking every intra-frame, and according to some of its Hollywood supporters including Ari Emanuel, this may be enough to eliminate the need for DRM.

We shall see; I am hopeful. This kind of per-user watermarking has been prohibitively expensive, but OTOY estimates the cost at pennies per movie with their approach.

Oculus Rift, Lightfield displays, Holodecks, and beyond. OTOY works with Paul Debevec of USC’s Institute for Creative Technologies. This is Tony Stark stuff, coming at us super-fast and soon to be delivered via JS, WebGL, and ORBX.js running in the browser.

I was thrilled to be included in today’s event, hosted at Autodesk‘s fabulous San Francisco offices. I gave a demo of Epic Games Unreal Engine 3 (Unreal Tournament, “Sanctuary” level) running via Emscripten and asm.js at full frame-rate in Firefox Aurora, and spoke about how JS will continue to evolve “low-road” as well as “high-road” APIs and features to exploit parallel hardware.

As Jeff Kowalski, Autodesk’s CTO, pointed out, the benefits go beyond major cost reduction in CGI and similar processing work, to increase collaboration and innovation radically, by relieving creative people from having to sit at big workstations. The GPU cloud means many alternative ideas, camera angles, etc., can be tried without waiting hours for each rendering. Even from the beach, via your 4G-connected tablet. Teams around the world can collaborate closely as timezones permit, across the web.

We will continue to collaborate with OTOY; I’ll post updates on this topic. It’s hot, and moving very quickly. Kudos to OTOY for their brilliant innovations, and especially for porting them to JS and WebGL so quickly!

When we at Mozilla say the Web is the platform, we are not bluffing.

/be

P.S. Always bet on JS!

P.P.S. Hat tip to Andreas Gal for seeing far, with Broadway.js.

If you’re going to San Francisco
Be sure to wear some flowers on your hair^Wantennae?!?

(With respectful apologies to the late Scott McKenzie’s song from 1967: “If you’re going to San Francisco, be sure to wear some flowers in your hair…”)

protip: I like how the flowers aerodynamically sweep back, and how zipties keep the flowers safely attached when driving fast.