Robert Accettura's
Fun With Wordage

It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:

var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, ...
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?

The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.

(more…)

So the format war of Blue-ray vs. HD-DVD is over. There are still several other rather significant battles going on in the tech world right now that aren’t Microsoft vs. Apple or Yahoo vs. Google. For example:

Adobe Air vs. Mozilla Prism vs. Microsoft Silverlight

Google Gears vs. HTML5 Offline support

Android vs. iPhone SDK vs. Symbian

Ruby On Rails vs. PHP

Not every case will have a true “winner”. That’s not really a bad thing. Choice is good. In some cases they will merge to form one standard, such as what’s likely for offline web applications.

What is interesting is that SQLite really dominates right now. Adobe Air, Mozilla Prism, Google Gears, Android, iPhone SDK (likely through Core Data API), Symbian, Ruby On Rails (default DB in 2.0), PHP 5 (bundled but disabled in PHP.ini by default). It’s becoming harder and harder to ignore that SQL survived the transition from mainframe to server, and now is going from server to client.

No longer is the term “database” purely referring to an expensive RAID5 machine in a datacenter running Oracle, MySQL, DB2 or Microsoft SQL Server. It can now refer to someone’s web browser, or mobile phone.

This has really just begun to have an impact on things. The availability of good information storage, retrieval, and sorting means much less of these poorly concocted solutions and much better applications. Client side databases are the next AJAX.

Edit [2/27/2008 9:14 AM EST]: Added Symbian, since they also use SQLite. Thanks Chris.

Mozilla Prism is an interesting product. What I really like is that it requires no real extra work for your app to run in it. With some additional effort you can potentially add some great stuff (offline support for example). It’s too early to develop applications for it just yet, but it does show off some serious potential. I did two tests as an example:

Google Calendar

Url: http://calendar.google.com (SSL doesn't seem to work at this time)
Name: Calendar
[ ] Show location bar
[ ] Show status messages and progress
[x] Enable navigation keys

Create Shortcuts
[x] Desktop
[ ] Start Menu
[ ] Quick Launch Menu

CBSNews.com Video Player

Disclosure: My employer.

Url: http://www.cbsnews.com/sections/i_video/main500251.shtml
Name: CBSNews.com Video
[ ] Show location bar
[ ] Show status messages and progress
[x] Enable navigation keys

Create Shortcuts
[x] Desktop
[ ] Start Menu
[ ] Quick Launch Menu

Both worked nicely. It gave me a way to keep the app open independently of my browser. The second test proves the next thing I wanted to mention. Plugins are supported. No reason why you can’t use a Flash player for example. Of course you could also use <video/>. I wonder if Google Gears could be installed on it? You can use about:plugins as an application URL to see what plugins are installed (I believe it should be the same as Firefox). There doesn’t seem to be an about:prism just yet.

There are however some security aspects that an application like this must take into account.

Improvements

There are a bunch of things I’d love to see. For example:

• API for Interactions - For certain events such as minimized/maximized (or user-visible/user-hidden to make it more neutral in terms of meaning). Also one for for opening a file so that the OS could map a file to be handled by an Mozilla Prism Application. The event could be handled similar to that of an upload. Haven’t looked to see what WHATWG offers in regards to these two things.
• Extensions Support - Think of this as an interface/vehicle for XULRunner. Full window apps like Calendar could be run in Prism. This provides a common runtime shared across multiple applications.
• Install Mechanism - To share the two things I did I had to document my settings up above. The ability to pass those perhaps using a protocol would be really nice. For example:

  prism://url=calendar.google.com/&name=calendar&enableNavigationKeys=true&createShortcuts=prompt

  would then open prism who would then ask you if you want to “install” this application. Bonus points if it accepted a base64 encoded icon similar to a data:URL and used it. Using an technique similar to what Apple does for iTunes and having a landing page would give the user the option to install Prism if they didn’t have it already.

Great stuff. I can’t wait to see where it goes from here.

Edit [10/29/07 @ 11:45 PM EST]: Fixed bad URL in example.

In case you were wondering what Google Gears meant to the planned support for Offline Web Applications in Firefox 3.0, here’s an article you may be interested in. No definitive answers, but does mention the possibility of combining ideas.

Google Gears is pretty cool, but I’d be much more comfortable if Google submitted the API as part of WHATWG and it were standardized. Google Gears would then be the way to use it without a browser having native support. I personally don’t like the idea of competing implementations.