Coding In Paradise

Two new bits of news today.

First, Jean-Baptiste Boisseau has done some great work porting Dojo SQL to work not only on Gears, but in a Java and AIR environment (and HTML 5 when that appears). His work is in alpha and can be seen here, including a demo here. He has setup a blog as well to track his progress. Just in case you don't know Dojo SQL is an easy-to-use SQL layer for JavaScript. Under the covers it uses Gears to do the actual storage, and now Java if available thanks to Jean-Baptiste Boisseau.

Second, Russell Leggett was inspired by all the talk around the Open Web and Gears. Russell likes the Open Web, but wants to see JavaScript, HTML, CSS, etc. not just evolved but replaced by better layers that can help with web applications; he just wants to see these new layers remain open, just like HTML. I told him that Gears could potentially act as a way to deploy some of his ideas, and challenged him to write up his ideas and create a blog. Russell accepted the challenge and setup a new weblog, named www.fightfortheopenweb.com, as well as a Google Group here. Join the group and join the discussion!

Some excerpts from Russ's first few blog posts:

"I believe there is an alternative solution [to Flash/Silverlight/AIR/etc]. I believe it is possible to fight fire with fire. If Flex/Silverlight/JavaFX threaten the open web, is there a way to compete on the same playing field? If the w3c technologies can't compete, can we take a different route? I propose that one very real solution to the problem would be to create an open source plugin technology to compete. It would allow a few things. First of all, it could ignore backwards compatibility because there would be nothing to be compatible to. Secondly, the cross browser issue would be resolved by being a plugin instead of a single browser implementation."

"I recently had a conversation with Brad Neuberg about the concept of using a plugin to have an Open Web competitor. Brad suggested that this was precisely what Google Gears was trying to do (sort of). In a recent post of his (which has since sparked a conversation across the blogosphere), Brad discussed the definition of the term Open Web and its importance, but also how Gears can help to push the web forward. In our conversation, he asked, "If you were to add functionality to Gears that doesn't enhance the web's existing technologies, but rather creates new ones that live in the browser through Gears what would these look like?" The following was my response:"

Russ wants better data-binding primitives and a refactoring of CSS to include variables, better layout management, and hooking into some kind of new component model for the web.

Russ also isn't gung-ho about JavaScript 2:

"I'm in the group of people that isn't totally gung ho about JS2. I understand the motivation, but its looking like a bit of a kitchen sink language. I think JS needs some improvements, but I'm actually looking at Erlang for inspiration instead of Java and Python. In my vision of a future JavaScript, I see a few things. First of all, I think there are some functional language features that would be good to add considering JavaScript is already a very functional language. I would like to add overloaded functions that use matching and guards for differentiation. I would also like to steal some aspects of the big Erlang feature of concurrent processes. Here, I think, is a perfect convergence with Gears. The Gears worker pools are a lot like Erlang processes (which I'm guessing you knew). No shared state, separate process, and no access to the dom. As I'm sure you know, this can be extremely helpful when trying to stay secure doing mashups, offload intensive operations from the main thread, and communicate with the server. Additionally, I think that there needs to be a little more in the way of modularizing code, allowing private data members, and facilitating better code reuse. I think prototypal inheritance and mixins are definitely better than classes for the language, and I'd like to add some more syntax to encourage them."

As they say in open source, code rules, so I told Russ to grab the Gears source and build it. We can have lots of discussions about how the web should be, but nothing speaks like actually getting a Gears module out that rolls some of the ideas above, at least in prototype form.

Labels: dojo storage, gears, open web

Hi folks; I'm going to be talking about Gears this spring at Google I/O in San Francisco. I'll be helping to run a codelab taking you through Gears and PubTools, and showing you the dark arts of cross-domain mashups using Gears. There are also some cool talks on building offline architectures from the folks that brought you offline Google Docs. Aaron Boodman will be talking about how Gears helps get HTML 5 out.

In case you don't know, Google I/O is a two-day developer extravaganza focused on the web and Googley APIs, such as OpenSocial, Android, etc.

Labels: gears

Folks toss the term "Open Web" around a bunch, but what exactly is it? Is the Open Web HTTP, HTML, JavaScript, etc., or is it something deeper? Rather than a laundry list of technologies the Open Web is a set of philosophies. These philosophies include:

• Decentralization - Rather than controlled by one entity or centralized, the web is decentralized -- anyone can create a web site or web service. Browsers can work with millions of entities, rather than tying into one location. It's not the Google or Microsoft Web, but rather simply the web, an open system that anyone can plug into and create information at the end-points.
• Transparency - An Open Web should have transparency at all levels. This includes being able to view the source of web pages; having human-readable network identifiers, such as URLs; and having clear network entry points, such as HTTP and REST exposes.
• Hackability - It should be easy to lash together and script the different portions of this web. MySpace, for example, allows users to embed components from all over the web; Google's AdSense, another example, allows ads to be integrated onto arbitrary web pages. What would you like to hack together, using the web as a base?
• Openness - Whether the protocols used are de facto or de-jure, they should either be documented with open specifications or open code. Any entity should be able to implement these standards or use this code to hook into the system, without penalty of patents, copyright of standards, etc.
• From Gift Economies to Free Markets - The Open Web should support extreme gift economies, such as open source and Wikis, all the way to traditional free market entities, such as Amazon.com and Google. I call this Freedom of Social Forms; the tent is big enough to support many forms of social and economic organization, including ones we haven't imagined yet.
• Third-Party Integration - At all layers of the system third-parties should be able to hook into the system, whether creating web browsers, web servers, web services, etc.
• Third-Party Innovation - Parties should be able to innovate and create without asking the powers-that-be for permission.
• Civil Society and Discourse - An open web promotes both many-to-many and one-to-many communication, allowing for millions of conversations by millions of people, across a range of conversation modalities.
• Two-Way Communication - An Open Web should allow anyone to assume three different roles: Readers, Writers, and Code Hackers. Readers read content, Writers write content, and Code Hackers hack new network services that empower the first two roles.
• End-User Usability and Integration - One of the original insights of the web was to bind all of this together with an easy to use web browser that was integrated for ease of use, despite the highly decentralized nature of the web. The Open Web should continue to empower the mainstream rather than the tech elite with easy to use next generation browsers that are highly usable and integrated despite having an open infrastructure. Open should not mean hard to use. Why can't we have the design brilliance of Steve Jobs coupled with the geek openness of Steve Wozniak? Making them an either/or is a false dichotomy.

Notice something very important; at no time above did I bind the Open Web to a particular set of technologies. Today the above philosophy is instantiated using a particular set of technologies, including URLs, HTTP, HTML, CSS, JavaScript, etc. However, if we define the Open Web in terms of these technologies, then we risk losing sight of what makes the web special and being able to have the intellectual nimbleness to evolve the infrastructure of the web. For example, we can and should evolve better layout languages than CSS, better document formats than HTML, etc., especially if we want the web to survive as a long-term social institution and public good, similar to the electricity grid, public-water systems, etc. We will be fighting yesterdays battle while allowing new, proprietary technologies to take over if we focus on technologies rather than philosophy. If we take the long term view, how can we give the web an open enough infrastructure to evolve over time and meet each generations needs, while maintaining its structure enough to actually mean something and stay true to its promise, similar to the U.S. Constitution?

The Open Web is like something from an Arthur C. Clarke science fiction story: its a globe spanning, hypertext network containing billions of documents, conversations, and applications, used by a huge cross section of society. Who would have thought it ever would have been successful or stayed as open as it has? It's not controlled by any one government or company. Our historical closeness to the web creates a kind of myopia, where we can't see how amazing it is. It's a billion Library of Alexandria's dropped into our laps.

Douglas Engelbart, father of much of what we have in the computer industry, including the mouse, hypertext, and groupware, thought that computers would become as fundamental to humanity as the development of writing and language have been. Language is probably only about forty-thousand years old, while writing is only about eight-thousand years old. If you pull back and take the larger view, the web and computers are part of a grand development playing out over decades around new tools for communication. Writing and language have fundamentally changed our sense of self, with positive and negative ramifications; computers and the web hold the same promise, though it will take decades for this to play out.

If the web and computers hold this promise, its important to keep the resulting system as open and accessible as possible. Do we want a system that devolves into something like Ancient Egypt, with an authoritarian force controlling and centralizing the water supply? Many archaeologists believe that deep control of access to water, literally something required for life, lead to the longest known authoritarian civilization in history, lasting for thousands of un-broken years. For example, what if the pencil and paper had never escaped the grasp of the Church? If we can keep the open web nimble and open, it can set the stage to fuel further innovations and inventions, just as writing and language gave rise to books, social polities, etc.

If we agree that the Open Web is important, how do we create a way to update the web and keep it relevant? The U.S. Constitution, for example, includes special provisions to evolve itself and stay relevant. Even with its warts, the U.S. is now the world's oldest and continuous republic.

The web's existing update mechanisms just don't work. It takes years for new features to go from proposal to show up across enough browsers to be used consistently; this is a recipe for fail if we want the web to exist as a long-term entity, rather than a one-hit wonder.

I joined Google to help with a project known as Gears. Gears is an open source plug-in that teaches current web browsers new tricks. Gears is a clever way to raise the bar cross-browser and cross-platform, today, running inside of Firefox and Internet Explorer on Windows, Mac OS X, and Linux. No more waiting years for features to show up across all browsers and platforms.

I want to look back five years from now and say that I worked with the community to build an open source update mechanism for the web. Why can't we rev the base infrastructure of the web much quicker, plus create more robust, open extension points along the entire web stack, ala Greasemonkey? Is Gears the answer to this? I'm not sure, but its the best answer we have today. Gears is a great way to get the conversation started, plus get HTML 5 out to today's browsers.

On a more prosaic level, Gears gets the following features into today's browsers without waiting years, ready to use by web devs right now:

• A real embedded relational database (SQLite) for web sites
• Client-side full text search
• Thread-like execution for JavaScript
• Offline web applications
• Secure and fast cross-domain mashups
• Desktop shortcuts
• Better web APIs for mobile devices
• and more.

[Disclosure: I work with the Gears team]

Labels: gears, open source, open web

Alex Russell recently had a great post called "Progress is N+1". An excerpt:

So as webdevs, we must be canny enough to find a way to [do] "better" which doesn't put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that's not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster. Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn't produce a roadmap, we'll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we're neglected by the browser vendors.

Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.

I posted a comment there that I want to replicate:

Alex, great post. This is why I joined Google and the Gears team. I believe in the open web and see Gears as a very clever solution to help get us out of the impasse we are all in as web devs. I'd like to look back five years from now and see how we, as a community, constructed an open source update mechanism for the web that cuts cross-browser and cross-platform, giving us leverage to move the web forward and rev it much faster than we have now. Gears is the closest to this we have today. As we say in open source, code rules, so drop on by Gears and contribute Gears modules that make this happen (http://gears.google.com). Want to see better 2D vector graphics show up cross browser that you can use today? Bake one into Gears.

Just in case you don't know about Gears or what it has today here's some more info:

Gears is an open source plug-in that teaches current web browsers new tricks. Gears is a clever way to raise the bar cross-browser and cross-platform, today, running inside of Firefox and Internet Explorer on Windows, Mac OS X, and Linux. No more waiting years for features to show up across all browsers and platforms. APIs include: A real embedded relational database (SQLite) for web sites; client-side full text search; threads for JavaScript; offline web applications; secure and fast cross-domain mashups; desktop shortcuts; mobile devices; and more.

I would add to the comment above and say that Gears, if we can get it embraced by the web dev community itself, means we can finally be in charge of our own destiny! Lets get an update channel into the web itself, vetted by the users and developers of the web itself.

Labels: gears, open web

Dimitri Glazkov, a prominent member of the Gears community, has a nice interview out. Some nice excerpts:

I am a software engineer at a company in Birmingham, AL, developing a content management engine for higher education and government Web sites across the country. My passion is building a better Web. A while back, I became convinced that a better Web starts with _not hating the Web_. And so began my quest into semantic markup, microformats, REST, and everything around them.

This part is so right on:

The Web has been and always will be defined by openness. Participation and social networking are just its logical extensions. It's pretty clear that the next frontier will have something to do with breaking down the barriers, imposed, knowingly or not, by the first generation of the social networking sites. The technology will have to play an important role in that charge. OpenID and OAuth are steadily gaining strength, and I am sure we'll start seeing the next generation of sites that value and appreciate user's freedom as well respect of content ownership. Also, as new features demand new capabilities, the browser becomes the weakest link. Looking at HTML5 spec and Javascript 2, my bet is on that changing really soon.

And of course the obligatory Gears shout-out:

NR: Do you have any current or future projects you're working on you'd like to share with us?

DG: Gears. That's an open-source project, led by Google, which aims to both level and elevate the playing field for Web developers, and allow them to step beyond the today's line in the sand. I am proud to be a part of the effort that's as open and pioneering as Google Gears.

NR: What does Google Gears let us do today that could help, say, Beth Kanter, do a better job of fund raising? How does it enable us to change the world?

DG: Gears could allow Twitter to finally build a site that handles traffic more gracefully by offloading some of the work onto the client, rather than keeping it all on the melting-hot server side.

Dimitri's been backing his statements up with code, helping out with creating an HTML 5 database implementation for Gears known as Database2.

Labels: gears

I've put up a new minor release of Gears PubTools that fixes a bug. You should grab it and replace your own instance with this since the bug fix is for creating shortcuts with the latest release of Gears. Learn more about Gears PubTools.

Labels: gears, pubtools

Wow, I didn't realize that you could create Internet Explorer binary behaviors with .NET. Behaviors are a feature introduced in Internet Explorer that allows you to attach new behaviors to existing tags or create new ones (i.e. I could create an ADDRESSBOOK tag and give it new behavior inside of HTML). Binary behaviors further extend this and allow you to write them in languages like C++, so you can do arbitrary 2D graphics for example or deeper extensions. It used to be that you had to know C++, but I just stumbled across a tutorial from 2003 where you could do it with .NET, which is much easier.

Labels: ajax, browser, dhtml, gears, hackery, internet explorer

I've put up a simple ZIP file that has just Dojo Storage. This is an optimized build of Dojo with just the small files necessary to use Dojo Storage. I've also created a simple Hello World example that folks can use to get started with Dojo Storage quickly. Note that this is a pre-release version of Dojo 1.1 which is coming out soon but has not been wrapped up yet. This version has a fully functioning Flash Storage Provider, HTML 5 storage, and Google Gears storage.

Labels: dojo, dojo storage, flash, flash storage provider, gears

Robin Monks, a Drupal hack3r, is already starting to think about and play around with Gears PubTools and see what it can do in the Drupal world:

Please view original blog post to see this Purple Included quote (I haven't hacked support for Purple Includes in my RSS feed yet -- wanna take a stab at that?)

Any Drupal hackers want to take this on?

Labels: gears, pubtools

I've created some simple utilities to make it much easier to use Google Gears without having to delve into JavaScript. This new open source library, named Gears PubTools, is a simple collection of JavaScript files that make it easy for content authors to work with Google Gears with just a little bit of HTML. With PubTools, you can easily offline-enable your content within minutes:

- Point to a Gears manifest file (a special file that lists all the pages to take offline) with a simple HTML attribute:

<html gears-manifest="manifest.js">

- Create a desktop shortcut icon that points right to your app and
use a custom image:

<html shortcut="true" gears-manifest="manifest.js">
<head>
 <link rel="shortcut.icon" title="32x32" href="icon32x32.png"></link>

- You don't even have to write the manifest file yourself! PubTools includes a simple bookmarklet that developers can drag to their browser's toolbar. Just navigate to the web pages you want offline, press the "Generate Manifest" bookmarklet, and a dialog will appear with the full manifest file generated for you ready to cut and paste into a file.

Quick Start

Want to get started using PubTools? First check out the simple demo page, then get started:

1) Use the PubTools bookmarklet to create a Gears manifest file. Go to src/manifest-bookmarklet.html to get the bookmarklet and follow the directions. Save this to a file, such as manifest.js.

2) In the web page you want to offline-enable, pull in the PubTools JavaScript file:

<script type="text/javascript" src="pubtools-gears.js"></script>

3) Point to your Gears manifest file:

<html gears-manifest="manifest.js">

4) If you want a desktop shortcut icon, add shortcut="true":

<html gears-manifest="manifest.js" shortcut="true">

You must provide at least one icon in PNG format; possible sizes are 16x16, 32x32, 48x48, 128x128. Providing all of them is best to allow the OS to choose the best one. Specify them using a LINK tag:

<link rel="shortcut.icon" title="16x16" href="icon16x16.png"></link>
<link rel="shortcut.icon" title="32x32" href="icon32x32.png"></link>
<link rel="shortcut.icon" title="48x48" href="icon48x48.png"></link>
<link rel="shortcut.icon" title="128x128" href="icon128x128.png"></link>

By default, PubTools chooses intelligent defaults for the shortcut icon. You can override these if you wish using META tags:

<meta name="shortcut.name" content="Test Application"></meta>
<meta name="shortcut.description"
content="An application at http://www.test.com/index.html"></meta>
<meta name="shortcut.url" content="http://www.test.com/index.html"></meta>

Most of these have sensible defaults and can be left out:
'shortcut.name' defaults to the HTML TITLE element if not present.
'shortcut.url' defaults to the page's URL if not present.
'shortcut.description' is optional and defaults to the string
"Offline Web Application"

Note that shortcut icons are only in the development version of Gears; the currently deployed version of Gears does not support shortcuts yet. PubTools will correctly continue to function if the user's installed version of Gears doesn't support shortcuts.

5) PubTools provides a simple default, optional UI for the user. To get this UI, add an element with the magic ID "gears-pubtools-offline-widget" into your HTML:

<div id="gears-pubtools-offline-widget"></div>

When the page loads, the user will see "Download Offline." When pressed, everything in the manifest is made offline and the shortcut icon is created if desired, with the user given feedback on the process. Now, the user will see "Delete Offline." By pressing this a user can delete the offline resources and start over at a later date.

If you don't want the default UI, your custom UI can call PubTools.downloadOffline() to initiate the download of offline resources, and can call PubTools.deleteOffline() to delete the offlined content. These can only be called after the page is loaded.

6) That's it! You're done. See the demos/ directory for a demo and boilerplate you can copy.

Quick note: Make sure not to list the pubtools-gears.js file in your manifest file. The manifest generator takes this into account to leave this out, but if you create it by hand leave it out. We do a trick where when you are offline we simply don't have the file, which doesn't display the default UI to the user since it makes no sense to show that when offline.

I've opened a code.google.com open source project for PubTools. I've done a bunch of QA testing on it, but make sure to file any bugs you might find. If you have patches send them in to me.

Labels: announcement, gears, open source, release

Alright, I'm going to give this new Purple Include quote stuff a try.

I promise this is not "Let's blog about Robert Scoble day," but, I guess it is :)

I just saw a great post by Scoble about how the Google Reader team could have prepped the community better before releasing a controversial new feature. Using some great advice from Read/Write Web, he asks:

(The stuff above was grabbed using Purple Include; now if I could have just hidden this parenthetical aside using Stretch Text.... future project... BTW, if you are reading this in an RSS reader Purple Includes don't work in my feeds yet -- see Scoble's original post to view the list)

I really like the list that Scoble & Read/Write Web provide. In fact, I've turned it into a checklist of things I should make sure to try to do when working with the community around Gears when there is a significant new feature:

• Did we show anyone at a conference the new feature?
• Did we do a video?
• Did we brief bloggers ahead of time and get their feedback?
• Did we show our #1 customer/user these features and get their feedback?
• Did we give an interview to a video journalist like Kara Swisher (or Robert Scoble) before release?
• If we are about to release, are we targeting Tuesday, Wednesday, or Thursday, versus other days?
• Do we have a demo to show off?

I'm printing this list out and putting it up on my wall here at Google.

Disclaimer: As always, I speak for myself and not my employer, Google.

Labels: community, gears, hypertext geekery, PR, scoble

My buddy Niall Kennedy has added Google Gears support to his weblog. While most folks think of Google Gears as just a plugin that helps you go offline, it also includes interesting tools that can help with web site performance, such as a local server that can serve resources and a local database for storing client-side data. Niall specifically used Gears to improve the performance of his blog by having all the images and resources of his blog get cached into the Gears local server. The end result of this is that when users hit his site in the future, images and other ancillary resources are served from Gears rather than his remote web site, improving the load time of his page.

A similar effect can be achieved by simply turning on HTTP/1.1 caching for your images and scripts. However, this caching is on a file-by-file level. The nice thing about Gears is you can bundle an entire set of resources at once, versioning them. You do this with a simple manifest file that you put on your web server. Here is Niall's:

{
"betaManifestVersion":1,
"version":"1.01",
"entries":[
 {"url":"../css/design.css"},
 {"url":"../css/resume/style.css"},
 {"url":"site.js"},
 {"url":"../css/images/body_bg.gif"},
 {"url":"../css/images/frame_bg.gif"},
 {"url":"../css/images/roundcorners.gif"},
 {"url":"../css/images/blog-backgrounds.gif"},
 {"url":"../css/images/icons.gif"},
 {"url":"../css/images/feed-readers.gif"},
 {"url":"../css/images/img_bg.gif"},
 {"url":"../css/images/preview.gif"},
 {"url":"../css/images/postcomment.gif"},
 {"url":"../css/images/search.gif"},
 {"url":"../css/images/icons/email.gif"},
 {"url":"../css/images/icons/phone.gif"},
 {"url":"../img/headshot.jpg"},
 {"url":"../css/images/headers/about.gif"},
 {"url":"../css/images/headers/contact.gif"},
 {"url":"../css/images/headers/home.gif"},
 {"url":"../css/images/headers/personal.gif"},
 {"url":"../css/images/headers/resume.gif"},
 {"url":"../css/images/headers/soccer.gif"},
 {"url":"../css/images/resume/msft.png"},
 {"url":"../css/images/resume/technorati.png"},
 {"url":"../css/images/resume/nextag.png"},
 {"url":"../css/images/resume/callan.png"},
 {"url":"../css/images/resume/aeosports.png"},
 {"url":"../css/images/resume/amex.png"},
 {"url":"../css/images/resume/pricegrabber.png"},
 {"url":"../css/images/resume/ucla.png"},
 {"url":"../css/images/resume/java.png"}
]
}

If Niall wants to refresh all of these resources, he can just change the "version" number; Gears will then refresh all of the resources when this happens.

Read more info on manifest files here; Dion Almaer has also written a tool that can help generate them for you.

Note that the manifest file isn't enough; you will need to create a bit of JavaScript that loads the manifest file for Gears. It would be cool if Gears would do this automatically, perhaps when the file has a well-known name on the root, such as /x-gears-manifest.json or something; note that this isn't on the roadmap right now -- it's just a random idea from me.

Niall also tied in a bit of reporting so he could track how many of his visitors are using Google Gears using a clever trick. In his JavaScript he put some Urchin tracking code to see how many folks grabbed the Gears manifest file (Niall told me it was ok to share this):

store=server.createManagedStore('niallkennedy');
store.manifestUrl='/js/gears-config.json';
store.checkForUpdate();
urchinTracker('/js/gears-config.json');

Now if Gears initializes and is present, we reached the urchinTracker() call and the fact that Gears was initialized is registered with Urchin. BTW, if you don't know what Urchin is its a tool that you can plug into your web pages to get analytics and find out what pages are being accessed and how.

Labels: gears, google gears, weblog

When Google Gears was announced this was a bit how I felt based on some of the wrong news that was in the press:

Google Gears the first offline web application toolkit?

"One thing I hate that the IT Industry is that when someone releases a piece of technology that is completely revolutionary, and no one takes stock, however when some company with a lot of clout in the industry such as Google or Apple release, everyone think that they rock!

From my RSS feeds I stumbled across this article in ZDnet "Can Microsoft change 'gears' for the sea-change ahead?". The title was attractive so I started reading it, however early on in the article I came across this:

"During that time, I have drawn attention to the work being done with JavaDB and Derby as examples of how the offline problem might get solved. But, ultimately, I have routinely said that when the problem gets solved, it will get solved by Google. Last week, with Google's announcement of Google Gears, that day came."

Once I read this I stopped reading why? Because Google Gears is NOT the first offline web application toolkit. The first on to my knowledge is Dojo Offline. Dojo is a popular AJAX framework, and Dojo Offline extends basic Dojo's capabilities by allowing Dojo applications to be used while you're offline....So why is it that the IT industry does not recognize achievement and give credit where it's due?"

Thanks for the blog post Irfan!

I actually just sent David Berlind, the author of the ZDNet article, the following email:

Hi David! My name is Brad Neuberg; I created an offline open source framework named Dojo Offline in conjunction with SitePen. I wanted to point to an inaccuracy in one of your articles:

"Can Microsoft change 'gears' for the sea-change ahead?"
http://blogs.zdnet.com/Berlind/?p=509

You claim that Google Gears is the first offline toolkit. In fact, Dojo Offline (and Dojo Storage) shipped before Google Gears with a similar model: a very-lightweight plugin that extended the browser to cache resources when offline, in conjunction with a simple API to help you build offline web applications.

As one of the 'little guys' who works hard to do my innovation out in the open and much of the time for free, it's important to me that I at least get credit when I create something before others. Most of my ideas usually sound weird and are ignored when I first float them, such as the offline problem which I've been attacking for the last few years, with focused solutions such as Dojo Storage, Dojo Offline, and others, or coworking when I first started it, so it's important to me that I get credit when they finally go mainstream so folks take me seriously on my next weird idea.

Best,
Brad Neuberg

Labels: dojo offline toolkit, gears