Google Gears for WebKit

Thursday, May 31, 2007 at 10:06 AM

Posted by Dan Waylonis, Mac Software Engineer

Have you heard about Google Gears? It's an extension to your favorite web browser and a new open source project from Google. It adds support for local data storage and helps web application developers manage resources so you can make your web application work offline. It is currently available for Linux, Windows, and Macintosh platforms and you can learn more at I got a chance to work on this product for WebKit, which is the render engine Safari is based on, and we're happy to announce that the source code is available to all Mac developers today.

Since Google Gears is leveraging the latest technology from WebKit, it is currently not compatible with the shipping versions of Safari (Mac OS X 10.4.x and 419.x). So, if you want to play with Google Gears for WebKit, you'll have to download a recent WebKit build from

How it works

Google Gears for WebKit is made up of an Internet plugin for Webkit or Safari (Gears.plugin) that's installed into /Library/Internet Plug-Ins and an InputManager (GoogleGearsEnabler) that's installed into /Library/InputManagers. The GoogleGearsEnabler ensures that Google Gears can provide resources to web applications. It registers a NSURLProtocol class only if the OS X Application is a supported version of Safari or WebKit. Once installed, the registered class will check any URL requests to see if Google Gears can provide the content. If so, it will intercept the call and provide the data. Otherwise, the URL will be processed normally. This is how Google Gears is able to work when you're not connected to the Internet.

Google Gears is an open source project and we're working with partners like Adobe, Mozilla, Opera, and others to make sure this is the right solution for users. So come check it out for yourself at and help us make it even better for WebKit and Safari.

Google Developer Day

Wednesday, May 30, 2007 at 12:02 PM

posted by Scott Knaster, Technical Writer

Seasoned Mac developers and fans know that Apple's upcoming Worldwide Developer Conference (better known as WWDC) is a highlight of every year. And for the first time this year, we are getting into the developer conference act too -- with tomorrow's Google Developer Day. It's not strictly a Mac event, but I'm looking forward to it because GDD is going to showcase all sorts of cool web-based cross-platform goodies, including Google data APIs, developing with Google Maps, AJAX development, and lots of fun with mashups (I got to help out with that topic).

Google Developer Day is a tough ticket, but I'm happy to report that we're webcasting the whole thing live and then posting the videos to YouTube, so you can virtually be there without having to travel. And if you are actually there, maybe we'll run into each other -- or if not, then maybe at WWDC.

Measuring performance of distributed notifications

Thursday, May 10, 2007 at 4:16 PM

Posted by Mike Morton, Software Engineer

On April 4th, we announced Google Updater. It uses several pieces of software that run in the background, but we knew early on it was important for the one user-visible application to be able to show you what those background pieces were up to.

We looked briefly at using Apple's Distributed Objects technology, but it can take a fair amount of work to make DO work well. We also need multiple copies of the user interface to listen to a single background process, so the logical way to implement it was NSNotificationCenter, a class in Apple's Foundation framework that broadcasts notifications across processes. It can even broadcast to applications run by other users logged into the same computer.

We did have one worry, though. Apple’s doc warns that “Posting a distributed notification is an expensive operation. The notification gets sent to a system-wide server that distributes it to all the tasks that have objects registered for distributed notifications…”. This left me wondering two things:

(1) Just how expensive is it? How many notifications can you broadcast per second? As with all Google client products, we want to be good citizens and not bog down the client machine.

(2) Does subscribing to any distributed notification really mean that the server sends you every notification, and not just the ones you asked to receive? Could we assume that the server keeps track of the “names” you ask to hear about, and filters before distributing?

One of my favorite riddles is “How many empiricists does it take to change a light bulb?”. So I wrote a command-line tool that broadcasts NSDistributedNotifications and another that listens. I ran ten copies of the listener and one broadcaster on a 2GHz Intel Core Duo.

The first interesting result was that the broadcaster can consistently push out a notification about every 2.64 milliseconds, no matter whether the listening processes are listening for the same name-and-object.

The second finding was that nothing burns much CPU except Apple’s distnoted process, which is the bottleneck through which all notifications get sent. When the listeners did listen for the name the broadcaster was sending, distnoted used about 30% of the CPU. Shark showed distnoted was spending time in memory management involving simple data structures.

So we can conclude two things:

• We can easily send several messages per second to a dozen or so listeners without impairing a client machine.

• Registering to get only the name/object you want can help performance.

We designed our background processes to limit the number of notifications they broadcast, and distributed notifications have been a great base on which to build this part of the Updater system.

P.S. The answer to the riddle: “I don’t know, either. Want to find out?” ;-)