Unified quota and temporary storage: part 1 – Unified quota

I promised that I blog about unified quota and temporary storage once the last “infrastructure” piece lands (bug 785884), so here’s the first part of the story.

Unified quota

Currently LocalStorage, AppCache and IndexedDB all use separate quota and usage reporting mechanisms, which is obviously suboptimal especially from the user point of view, so we decided to unify it.

The idea was to abstract IndexedDB quota handling and plugin other storages to it, but as we started adding new features to SQLite’s extension for quota handling (test_quota.c), we found out that the extension is not very flexible and we need an own quota manager implemented in C++. A rewrite of quota handling (bug 787804) landed exactly 9 months ago. The new quota manager is much cleaner way of quota handling and it also fixes some performance problems. One of them was that when a thread reached the quota limit and it needed to ask the user for the quota unlimited permission,  it blocked all the other threads (even for different origins).

Once we had the new quota manager we could start working on a “centralized” quota and storage manager (bug 767944) which landed early in Q2 of this year. The centralized manager is designed to jointly handle quota and storages (for example coordinated operations on top of an origin such as opening of databases, usage reporting and clearing of data) of all current and future storage APIs. At the moment, there’s only IndexedDB plugged into this manager, work on plugging LocalStorage should start soon and the new FileSystem API implementation will clearly use the new quota manager.

Next time, tempory storage.

Firefox OS: The motivations and the goals

I gave a talk at Openmobility conference in Bratislava last weekend on the motivations and the goals behind Firefox OS. Here’s the full text of the talk.

Firefox OS: The motivations and the goals (Openmobility 2013, Bratislava, 7th of April 2013)

Abstract
The walled gardens of today’s dominant mobile operating systems frustrate both developers and customers. Mozilla seeks to create a truly open platform called Firefox OS.
In this presentation Jan Varga will speak to the motivations and primary goals of Firefox OS from a technical perspective.

1. Introduction
Today, I’d like to tell you something about Firefox OS, the new mobile operating system which is based on open technologies and is also developed as open source software.

2. The current situation and the history
As you may all know, there are two dominant mobile operating systems. They are developed and supported by two big companies. There are also other operating systems, but they have only marginal market share. Even Microsoft with its own mobile operating system is not able to break the duopoly. Duopolies are bad for competition, they slow down innovation and are generally bad for users. The first operating system is closed and its app store is so-called walled garden, controlled by a single company. App developers are forced to distribute their apps through the app store and they have to use company’s payment system too.
The second mobile operating system is “open”, but it’s not open in the sense of how we understand openness. When we look at history, we experienced a similar situation when the market share of Internet Explorer peaked around 96% in 2002. Fortunately Mozilla released Firefox 1.0 in 2004 which revived competition and standardization of web technologies.
We think that the solution for mobile is to come with true open source operating system based on web standards.

But let’s look at the problems of the one or two dominant players. Back when IE had 96% market share Microsoft didn’t have to standardize new APIs at that time and web developers started optimizing only for Internet Explorer. We can see a similar temptation in the mobile market too – “optimized for WebKit”. There are people who think that Microsoft, Mozilla and Opera should just ditch Trident, Gecko and Presto rendering engine and switch to WebKit. They think it would solve many if not all the problems which web developers are currently facing. This idea was further discussed when Opera recently came out with an announcement about switching to WebKit. The problem is that WebKit is not united at all. At the very least there are company specific features and bugs which it brings. A good example is the File System API supported in Chrome, but not in Safari. It’s funny that I had to modify this presentation just because a few days ago Google announced that they are forking WebKit, the new rendering engine will be called Blink, and the number of main browser engines will be five again and that’s good.
But there’s also a practical example of how the monoculture can be dangerous. Implementation of the WebStorage API that is intended for storing data locally through the browser differs a little across the browsers. All the browsers except Firefox don’t check data usage per domain (specifically per eTLD+1 domain). So it’s possible to create multiple subdomains with each having 5 MB limit and in theory fill in entire user’s local disk. This theory was “explored” by a guy who created so called “HTML5 Hard Disk Filler™ API”. It provides essentially unlimited storage space on visitor’s computer using one of the browsers except Firefox. The intention is not to promote Firefox as the most secure browser here, but imagine a situation when we only had one or two browsers with the same issue. There could be sites that rely on subdomains’ space not being counted toward the parent domain’s space, and it it would be impossible to fix this bug without breaking the Web. But because we don’t have monoculture and some browsers implemented subdomain limits, web sites haven’t been able to rely on this behavior. So the affected browsers will be able to fix the bug without breaking the web, that is both better for them, and for the web.

Another big problem is that the two dominant mobile operating systems are completely different platforms (Objective C versus Java) and they have different app stores. It means that apps have to be developed for both platforms separately, but not only that. If you like a mobile phone made by company X but you prefer a tablet made by company Y and you want to use the same app which is not free on both devices, then you have to pay for it twice. Commercial companies have usually only one primary goal, that is to make money. Mozilla on the other hand is a non profit organization caring for user’s interests and privacy in the first place.

So we’re trying to open the mobile market as we did with the web back in 2004.

That’s just a brief description of the motivations and the goals behind Firefox OS, let’s talk now about technical aspects of Firefox OS

3. Firefox OS
Firefox OS is made up of the three main layers; Gonk, Gecko and Gaia. Gonk consists of a Linux kernel and a hardware abstraction layer, Gecko is actually the same rendering engine that powers the Firefox browser and Gaia is at the top level providing the user interface and all the basic apps like the dialer, sms messaging, settings, etc. Other apps can be installed via a marketplace (installed apps) or just by going to a website which supports Firefox OS (hosted apps). As you can see, apps can be installed via different marketplaces or from websites directly.

Apps for Firefox OS can have one of three privileges; Certified, Privileged and Untrusted. Certified apps are system apps that have been approved by the operator or OEM (for example SMS, camera, the default dialer), they have access to all Web API operations (for example telephony). Privileged apps are third party apps that have been reviewed, approved and digitally signed by an authorized marketplace. Untrusted apps include everything else (both installed and hosted apps).

All these apps are implemented using open standards such as HTML5, CSS and JavaScript, even the dialer. This provides a unified platform for all devices like desktop computers, mobile phones and tablets. HTML5 is already used on the web, so developers don’t have to learn a new programming language or to get familiar with a new technology. Actually there are many more web developers than there are developers experienced in developing apps in Objective C or Java.

4. Performance
Some people think that HTML5 is not mature enough, that native apps will always run faster on mobile, etc. Probably the best way to measure level of maturity is to run games, especially popular games like Cut the Rope. Cut the rope running on a mobile phone with Firefox OS has been demoed not so long ago at the MWC 2013 in Barcelona, and it ran really smoothly. I’ve heard that the demo left journalists speechless.
The times when JavaScript was a purely interpreted language are gone. When we compare performance of code running in highly optimized JavaScript engines with compiled code (typically written in standard C language), JavaScript is only about 4-5 times slower. However that’s still not enough for 3D games.
There has been a research project at mozilla aiming to speed up the web for game development, including asm.js a JavaScript optimization technology and pure-JS-subset target language for compilers; Emscripten, a C++ to JavaScript compiler; and OdinMonkey, the SpiderMonkey JavaScript engine’s compiler for asm.js source. The asm.js technology is already supported in a development version of Firefox (a nightly). It’s early to judge, but preliminary benchmarks of C programs compiled to asm.js are usually within a factor of 2 slowdown over native compilation with clang. This effort has resulted into an announcement about mozilla teaming up with Epic Games to bring Epic’s Unreal Engine 3 to the web.

5. Conclusion
So as you can see HTML5, CSS and JavaScript are able to compete with native apps on desktop and on mobile phones too. There’s a way to simplify development of apps for mobile phones by providing a unified platform which is actually the web.
Mozilla’s aim with Firefox OS is not to gain a dominant position in mobile market (but we wouldn’t be sad if it happened of course :)), the aim is rather to show a path for others to use a similar approach. So in the end, the ones who will benefit from this are users and developers of apps.

 

Moving stuff to new DOM bindings

I landed my first patch that moves stuff to new DOM bindings, bug 854323. Everything was quite straightforward, there’s now documentation for WebIDL bindings which I followed. Anyway, I found a little thing that is not documented. An implementation object must inherit from nsISupports (directly or indirectly) first and then from nsWrapperCache. If the order is changed then the object is leaked. In the case of IDBFactory it leaked entire window since IDBFactory has a strong reference to it. So keep in mind, the order is important!

A Time for Mourning

My mother passed away a few days ago from a heart attack. I can’t believe it happened. I couldn’t help her even though I got to her in very short time.

She was my only parent, and meant everything to me, we were very close, and I will miss her terribly.

Her favorite song was “Little friend from the city N” and this song played at the funeral too.

Why can life be so cruel ?

Jan