gears

Bridging the gap between html5 and Gears

by

my trash in gmail mobileGoogle claims HTML5 on the web is the future of applications on mobiles and they present the high-end mobile version of Gmail (on iPhone and Android) as an example of what can be achieved with web-based applications. But, as I wrote earlier, the Android-browser does not support HTML5’s webdb, appcache or geolocation at all (and neither does Google Chrome). Instead Google offers similar (but different) functionality in their Gears-plugin.
Almost the same functionality, but with a different API, how did they implement mobile Gmail? Well, Appcache (a.k.a. “offline web application”) seems to be implemented separately. That  makes sense as defining which files can be stored locally is more or less a one-off job. But for more complex data-oriented offlining with a local database, Google created a wrapper-script that hides the Gears and HTML5-API’s and the underlying differences, thus offering a unified way to store and retrieve information from a local db. The code, including an example, can be found in WSPL’s svn-repository in Google Code.
And while it’s not used (or needed) in gmail, there also is a a geolocation-wrapper to abstract those HTML5 and Gears-implementations. Once the wrapper is instantiated, getting the user’s location on iPhone (OS3), Android and some others becomes as easy as doing:

geo_position_js.getCurrentPosition(success_callback,error_callback);

Great stuff, those wrappers. But wouldn’t it be even greater if Google’s browsers would support the native html5-specs, so these stopgap solutions  weren’t needed to start with?

Google to launch Chrome, a Webkit-based browser

by

Yesterday Google confirmed that it would be releasing a new browser in beta today, named Chrome. Everything there is to know about this new open source browser for now, can be found in an online comic.
Based on that publication, the most important features seem to be;

  • each tab runs its own sandboxed process (limiting the damage one tab or plugin within a tab) can do (as is also the case in MSIE 8 beta with what they call “Loosely coupled IE”)
  • it is based on webkit (remember khtml and Apple’s Safari and all those mobile browsers)
  • it features a new javascript virtual machine, build by v8, a Danish company
  • the ‘omnibox’ (cfr. the ‘awesomebar‘ in Firefox) is located on the tab-level instead of the window and is thightly integrated with (you guessed it) google
  • a new tab shows you your 9 most visited sites and your 3 most uses search-engines (a bit like Opera Speeddial)
  • it features a ‘icognito’ mode in which nothing is logged (cfr. InPrivate browsing in IE 8 beta 2)
  • google gears comes prebaked
  • it is not clear if Google used Mozilla’s XUL/chrome to build the UI elements, but the name might be an indication that they did and the comic does state that Google “owes a great debt to other open source browser projects, especially Mozilla and Webkit”, so …

Looks very interesting, i’ll download is as soon as it’s available later today. But I’m curious what the Mozilla-guys think of what must be a double dent in their ego with a friend gone foo (well, to a certain extent) and with Google not using Mozilla’s Gecko as html-rendering engine.
Update; a screenshot of the new browser:

WordPress 2.6 svn-upgrade; ouch!

by

WordPress 2.6 has been pushed out the door at Automattic and it contains some exiting new goodies as usual. So I fired up my trusty upgrade script, but got an ugly php-error when accessing the database update-pages:

Parse error: syntax error, unexpected T_SL in wp-includes/widgets.php on line 464

Turns out that the wp_widget_search-function in wp-includes/widgets.php included some remnants of an SVN-merge. Don’t know if it was a sync problem at my side or if the faulty code was on the SVN-server (it isn’t now), but I ended up copy/pasting the correct function from a fresh tar-ball I downloaded.