Getting Started Developing for Firefox OS Screencasts

I've been working on Boot 2 Gecko (Firefox OS) for the last 9 months now, and it has been both a completely insane project and an awesome project. Insane amount of work, awesome implementation.

Writing an OS from the ground up is no easy task. Luckily, we're not doing that. We are building on top of the linux kernel and gecko, both open source projects that have lots of effort put against them.

It is really starting to firm up now, especially after a few weeks ago when we had the feature freeze. There is still a lot to do, however, and we are going to be trying to bring in developers from other areas of the company to help fix bugs and make this thing stable.

Luckily, the development process just got a lot easier with two things that recently landed. One is that the b2g desktop nightly builds now include a build of gaia, so you can just download a nightly build, double-click, and go. The other is that the remote debugger gained the ability to load code over-the-wire as part of the debugger protocol, so the way gaia packages up apps and refers to them using app:// urls is now debuggable without nasty workarounds.

As we are ramping up newer developers to help with the project, we need clear documentation of the development process. The Gaia/Hacking page is the canonical reference for how to do absolutely everything, but it's overwhelming. To help with this, I made a series of 5 screencasts that cover the basics of using b2g desktop nightly builds, remote debugging with b2g desktop, hacking on gaia itself in b2g desktop, flashing a phone with gaia changes, and what to do if Firefox OS asks you to choose from two homescreens or if remote debugging does not show your source for your app.

As an aside, I find it hilarious that there are all these incorrect rumors about the speed and the memory of the phone, when the correct specs were actually *announced* in February. I guess people would rather speculate and spread rumors than read press releases.

B2G Desktop Intro (Firefox OS)

B2G Desktop Intro (Firefox OS) from Donovan Preston on Vimeo.

Debugging Gaia (Firefox OS) with the Remote Debugger

Debugging Gaia (Firefox OS) with the Remote Debugger from Donovan Preston on Vimeo.

Hacking on Gaia in Debug Mode

Hacking on Gaia in Debug Mode from Donovan Preston on Vimeo.

Flashing Gaia onto a Firefox OS Phone and Remotely Debugging a Firefox OS Phone

Flashing Gaia to a Firefox OS Phone and Remotely Debugging a Firefox OS Phone from Donovan Preston on Vimeo.

Firefox OS Tips

Firefox OS Tips from Donovan Preston on Vimeo.

Where are the Peer-to-Peer web apps?

Perhaps the reason we have not seen single-page html applications that connect directly to peers without an intermediate server is that browsers cannot easily listen on a local port. They can open outgoing connections all day long, but WebRTC may be the first web standard that allows the browser to listen on a port. If there are others, please let me know.

Of course, the WebRTC spec looks overly complicated for the incredibly simple thing I want to do. I just want the browser to be able to listen on a port like any other process on the machine can. Sure, there are security implications, but these exist for everything the browser exposes to web applications, and there's an entire class of Peer-to-Peer web apps that simply cannot easily be written using current web technologies.

There are many examples of a Peer-to-Peer experience being delivered to users using a client-server architecture. ChatRoulette, Omegle, and even more recently, products like Google Hangouts. These applications must be implemented by using servers in the middle to connect the peers, making scaling them much harder than it would be if browsers could just listen.

There is an opportunity to explore a generic Client-Agent-Peer architecture, where Clients (Browsers) talk to an Agent server using HTTP to configure the state of the Agent, which would then be contacted by the Peer on behalf of the Client when the Browser is not online. When the Browser is online, the Agent can refer the Peer directly to the Client. When the Browser is offline, the Agent can handle the request itself using a cached copy of the material the Browser was sharing, or it can just decline to fulfill the request.

Reverse HTTP was my attempt to push out the simplest thing that could possibly work to get browsers to talk to each other. It didn't really go anywhere in terms of being implemented in actual browsers. Coincidentally, someone else had the same idea around the same time, and implemented Reverse HTTP in terms of actual HTTP Requests encoded in Responses, and vice versa. This makes it possible to write a pure javascript client rather than needing the browser to support the Upgrade protocol itself.

Really, though, it would be very nice if all of the hacks and tricks and workarounds weren't necessary, and I could just listen on a port with javascript. I'll keep dreaming.