Monthly Archives: September 2009

Helping Mozilla to define “the open web”

Over at Mozilla Hacks Christopher Blizzard is asking readers to explain what “the open web” means to them.

My answer went something like this (it was slightly less elaborated and not as structured, guess I have a problem with character-limits):

The open web is an ecosystem based on free and open standards, allowing anyone to:

  • participate in evolving the standards
  • using the standards to build and use
    • server- or client-side infrastructure-type applications (e.g. Apache or Firefox)
    • websites and -applications, relying on the standards-compliant infra-type apps

without being limited by commercial or patent restrictions (per se).

It is my conviction that it were exactly these principles which allowed the WWW, as it was invented by Tim Berners-Lee (and Robert Cailliau off course), to become the success it is today. Sir Tim announced and published the first specs (specifically http/html) and asked people for feedback and encouraged them to put up servers and pages and to develop their own WWW-applications in 1991. In 1993, as a reaction to the University of Minnesota wanting to charge  license fees for Gopher,  CERN officially released the project into the public domain in 1993 with the aim:

“to further compatibility, common practices and standards in networking and in computer supported collaboration”

A few years later Gopher (which didn’t only suffer from the license-issue, but was less flexible as well) had disappeared completely, and the open WWW boomed and revolutionized the way information was published and consumed.

So the next time anyone asks you why “the open web” is that big a deal, you might want to ask them if they would rather Gopher instead.

Bridging the gap between html5 and Gears

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?

WebTech news (september 2009)

1. Mobile browsers; not all is WebKit:
Although webkit-based browsers dominate the mobile web with Mobile Safari on the iPhone, the Android browser on e.g. the HTC Hero and in the future also the Blackberry browser, there are other browsers around as well:

2. According to a Forrester-study, in 2014 28% of handset-owners in Belgium will use mobile internet. Not bad, but according to that same study, the European average in 2014 would be 39% with Holland attaining 47%.

3. Misc:

As found on the web (September 24th)

googlereader (feed #38)
blog (feed #46)
googlereader (feed #38)
googlereader (feed #38)
youtube (feed #48)
googlereader (feed #38)
googlereader (feed #38)
youtube (feed #48)
blog (feed #46)
googlereader (feed #38)
googlereader (feed #38)
googlereader (feed #38)
googlereader (feed #38)
googlereader (feed #38)
youtube (feed #48)
Liked 2 videos.

Impatiently flashing my HTC Hero into shape

the new android recovery image menu in actionI’m an impatient man, so although I heard rumors that Mobistar might be testing the HTC Hero update (which is Belgium-specific, as the YouTube application has to be removed because of privacy law concerns), I decided to go the “less official” way and root and flash the darn thing myself. The process was pretty easy (thanks for the info Thomas & Serge), the outcome is great; my phone is a better Hero for it!

So suppose you’re as impatient as I am, suppose you don’t care that this may void your warranty, suppose you’re not scared of bricking your brand new toy, suppose you’re a not entirely technically ignorant, then you could follow these steps:

  1. Root your HTC: by using flashrec.apk to flash a new recovery image on your HTC as described here. If you get a “backup failed” error in step 10 as I did, you just need to power off and on and try again (the backup itself isn’t used anyway, that step is just needed to have flashrec allow you to continue).
  2. Upgrade your rooted HTC: from the new recovery image menu flash MoDaCo custom ROM v2.x (I installed 2.2, 2.3 was released a couple of hours ago) to your system as described here. And don’t forget to wipe before flashing as I did.
  3. Update to the latest radio package to version 63.18.55.06EU_6.35.06.18 from the recovery image menu (you should know the drill by this step) for optimal radio performance.

But you could also wait for the official update, off course …

Nu zonder donkere kamer; diavoorstelling vakantie Centerparcs 2009

Met de knapste vrouw op aard en het liefste dochterken van dit (en het ander) halfrond tijdens de mooiste maand ter wereld op vakantie naar Centerparcs Lommel, leuk dat dat is;

<a href="http://picasaweb.google.com/veerlenijs/CenterParcs2009"><img src="http://lh3.ggpht.com/_XRyv6uqEWPQ/SrOz-wZ4t7I/AAAAAAAAAts/WaNouAcsZYk/s720/DSC_1179.jpg" /></a>

HTML5 offline webapps vs Google Gears Localserver

Google Gears is a fantastic browser plugin; it allows a developer to create applications that run while offline, syncing with a server when online. Two great examples of the power of that mechanism are Gmail (both the “desktop browser” and the mobile Android-version) and Mindmeister (only while in trial, for paying Mindmeister-accounts after that period). The problem with Gears however is that it’s a plugin and not a lot of people have it installed: only Chrome-users have it by default. And that’s where HTML5 comes in; one of the areas where the new spec offers vast improvements over html4/xhtml is the ability to take webapps offline by allowing a developer to store files for offline usage and to write data to a local, browser-embedded database. Both Safari 4 and Firefox 3.5 support these features, so maybe HTML5 makes Gears already redundant in those browsers with more to come?

I haven’t gotten around to experimenting with offline databases yet, but I did already look into offline files. At first sight, Gears Localserver and HTML5 Offline Webapps indeed seem very similar; your html-page points to a manifest-file which contains a list of assets (pages, images, css, js, …) that the browser has to store for offline usage. Easy enough, no?

To get a better feel of how offlining in HTML5 works, I decided to try to write a simple WordPress plugin to replace its ‘Gears Turbo’-option. Turbo (which you can find in the Options-menu) essentially stores 1Mb of files locally, to speed up delivery of the WP-admin pages. To make a long story short; my plugin didn’t work. For starters, by default requests for non-local data are blocked, but it’s easy enough to unblock network access by adding “NETWORK:*” (with a newline before the wildcard) to the manifest. But more fundamentally; HTML5 Offline Webapps not only stores the files specified in the manifest-file, but also every html-page which points to the manifest (see my test here). There’s no way you can exclude those “master entries” from being stored. So if pages are stored, that means they have to be static and that all dynamic parts should be handled by javascript (fetching data using ajax and updating your page with it). And that, my friends, is clearly not a use-case that is applicable to WordPress admin-pages.

So HTML5 Offline Webapps is no drop-in solution to speed up delivery of dynamic pages, you’ll still need Gears to take care of that (or rely on old-fashioned carefully configured expiry- and cache-headers). But, as Google proves with the iPhone-version of Gmail, Offline Webapps combined with a HTML5 offline database can work miracles if you use it the correct way.

http://blog.futtta.be/2007/04/06/cache-header-magic-or-how-i-learned-to-love-http-response-headers/