Skyfire exec talks up scaling mobile Web browser

Credits Apple iPhone for advances in mobile Web services

Skyfire is one of the companies with a vision of surfing the full Web from a mobile device, just as you do from a desktop. They just hired mobile programmer Mike Rowehl as scalability architect, to help them do it.

Who: Mike Rowehl Scalability architect Skyfire Labs, Mountain View, Calif. The hot new Skyfire mobile Web browser, now in limited beta for Windows Mobile devices The Skyfire browser is hosted on servers; Rowehl has to make sure each server can support the maximum number of users sessions, and that the software scales smoothly over multiple CPUs

Title:

Company:

Product:

The job:

Rowehl, a mobile software programmer, dropped out of Rochester Institute of Technology's computer science program after three years. That's not been a drawback: he has nearly a decade of experience designing and building open source, mobile applications for companies such as AdMob, Ning, Bitsplitter (his own company) and Feedster. He'd been consulting for Skyfire before being hired July 1, the first high-profile employee since Skyfire won $13 million in Series B funding in June. With Russell Beatie, his co-founder for now defunct Mowser, Rowehl launched Mobile Monday Silicon Valley, a monthly open meeting for folks interested in mobile applications.

A picture of a Skyfire on a phone.

When did your interest start in the mobile Web?

My first tentative experience was in 2003 and 2004. I was working in Europe for a company that did home automation and security. Our embedded Linux device was installed in the home, and we worked on a Web interface so home owners could access the device and check a security camera or change heating settings from their mobile phone.

Where did things stand in 2003 for the mobile Web?

Until recently you had to develop a custom Web site for mobile content. There were different markup languages and different protocols. Even if you were developing to an industry standard like WAP [Wireless Application Protocol, for presenting Web information on handhelds, developed by the WAP Forum, which folded into the Open Mobile Alliance], certain devices supported different capabilities. Some accepted certain kinds of shortcuts, some didn't. It was very difficult to get even a minimal functional set of features on a device.

What's changed over the past year?

There's been a convergence of the desktop Web and mobile device Web. There's still a need to tell your application [about the device] a lot of times, so the information displayed is relevant to users on the go or with a small screen device. And if you choose to optimize that further, you now have tools to do it with. It's not a major porting effort anymore.

The iPhone in particular has done a fantastic job. Since 1999, we've been asking 'what's the application that will cause people to pull out their phones and engage with other data services?' The iPhone really cracked that open, and people are starting to think differently about the services on their device.

The iPhone cracked it open how?

[With the Safari browser,] any Web site that's out there, minus Flash content, is useable on the mobile device. With iPhone, you go to CNN.com and get what you expect to see. The marketing push that Apple put behind this, in changing the average user's expectations, has been one of their major contributions.

And they made some major updates to the browser [user interface] – the nice big screen and the touch interface – which make it a pleasant experience to interact with the Web. Other browsers could render the page but it was hard to get useful information out of the page.

So what does Skyfire hope to introduce?

Two things. First, we're looking at the overall evolution of the interaction with the Web on mobile, the [new] expectation that any desktop Web site will be available on any mobile device. (See a video of Skyfire's debut at DEMO 08.)

Second, how to get optimized mobile content: pulling in information from the device to be used by the Web-based services. So how do we give the right hooks to developers to figure out things like the phone's screen width, so it can deliver the right content?

So the heart of this is the new mobile browser?

We're developing a browser, first, that's based on an existing open source browser's core: desktop Firefox. Anything available on that, we can build into our mobile browser.

Second, we're a proxy browser: there is a minimal set of functions on the phone, and the browser instance itself runs on a server. We offload the compute-intensive tasks to the server.

Are their tradeoffs with that kind of "thin client" browser approach?

A couple of things are problematic. It's not good for intranet or private browsing, of resources tied to a corporate network for example. To a degree, we also don't have access to local resources such as files on the phone since the browser is on the server. That's not a major shortcoming at this point.

What are the benefits of a server-based browser?

We're able to save a lot of compute power on the device. It has very small memory footprint, and low battery use. And there are significant savings in network traffic. In the U.S., this shows in faster responsiveness: we average 5-6 seconds to display a page vs. 20 seconds or more by Safari for the same page. We process on the server, and then start to download and display images on the phone as they're ready.

Hence the need for a "scaling architect," for this server-side infrastructure?

We're just in the beginning stages of figuring out how to get the most users supported per box, and user sessions per server. There are two kinds of scaling. Horizontal scaling is adding more servers, and you need an application structured appropriately to run efficiently on them, to run across multiple CPUs so we can expand capacity in a linear fashion.

Then there's vertical scaling: making sure we can run efficiently on these servers. Firefox 2.0 had a reputation for being memory intensive. Firefox 3.0 reduces this a lot, and we're looking to improve that still more, reducing overall memory needs and running more efficiently in what remains.

We're also looking at ways to reduce our network bandwidth, at how to get an optimized control stream back to the user, and, if users are shifting for example from cellular to Wi-Fi networks, how to make that relatively seamless in terms of server interaction.

It's an interesting set of problems.

What's the status of the Skyfire browser?

Right now, we're out on Windows Mobile in limited beta. General beta will be sometime this summer. Next, is porting to Symbian. We haven't announced a beta release date for that yet.

Your online information says you abandoned Windows for Linux way back 1998. What's your current handheld, and what browser do you have on it?

I have the Nokia N95, their multimedia device, and the Symbian pre-release version of Skyfire. When I'm not using that, I'm using Opera Mini, a direct competitor. I was really impressed with the Opera Mini advances. I can get a navigable version of a Web site on my phone, and it's fast. I also have a Windows Mobile device. That's mainly for testing.

Learn more about this topic

Startup sets full mobile browser free

Podcast: Six Minutes With ... Nitin Bhandari, CEO of Skyfire

Blogger Craig Mathias on the evolving mobile browser experience

From CSO: 7 security mistakes people make with their mobile device
Join the discussion
Be the first to comment on this article. Our Commenting Policies