Connectivity is only part of the user experience

There's an awful lot of interest in Google Gears right now (proving offline support for web applications), and rightly so. Other frameworks are jumping on the bandwagon too. Dojo can now utilize Gears, Adobe's ApolloAIR, and from Scoble's blog, a host of others will soon be supported too. The motivating factor behind the technology is: Hey, I'm not always connected, so let me download and cache the data I'll probably want to access so that I can navigate the web while offline. The motivation behind this is really: I'm not always online. And surely, the motivation behind that is: I'm mobile. And if you're mobile, you're probably not lugging around a desktop - you're more than likely on a laptop. This all begs the question: Surely there are more aspects to being "mobile" than "online"? And of course there are:

  • Power - you'll be sometimes connected (to the power socket) and sometimes not. Wouldn't it be nice if my web applications (heavy animations?!?) knew this and could react appropriately. "Hey man, don't open this Java applet as it's going to drain the battery."

  • Connectivity - you're not either online or not. It's a spectrum. You're sometimes connected, but slowly. Wouldn't it be nice if my web application would automatically adjust download resolution depending on my connectivity speed? (through a proxy, say)

Now imagine the mashups. You're in a dodgy coffee shop on a dodgy internet connection browsing a (dodgy?) site, and when you click a download you get your browser rendering a nice little warning: You don't have enough power to download this huge file given your current connectivity! Now that is Google Gears on steroids... I wonder if the Google Gears, Adobe Apollo and all the rest know about Intel's Web 2.0 TDK that lets you interrogate your machine to do all this...
Per informazioni più dettagliate sulle ottimizzazioni basate su compilatore, vedere il nostro Avviso sull'ottimizzazione.