As I continue to read through my backlog of Scoble’s posts (backwards), I find older and older stuff that peaks my interest. In this post, Scoble discusses the comments made by Jonathan Schwartz, Sun’s COO, which we’ve all probably heard by now:
Or finally, as I did last week at a keynote, ask the audience which they’d rather give up – their browser, or all the rest of their desktop apps. (Unanimously, they’d all give up the latter without a blink.)
Scoble provides a simple thick vs. thin client example: Outlook. The 2003 version of Outlook Web Access (the server-side web-based version of Outlook) kicks ass. It’s honestly almost exactly like the actual Outlook install. If we were running 2003 at work, you better believe I’d push like crazy to dump the actual Outlook client and have 90% of the company run it over the web. The only problem?
Yet I wouldn’t trade that for the real Outlook for anything. Why? Well, the real Outlook works offline. The real one is far easier to manipulate. The real one looks better. The real one doesn’t go away if I accidentally hit refresh (or, worse, walk out of network range).
This is a common complaint people have about web-based apps. It’s one of the reasons I refuse to use webmail entirely. 90% of the time, I have my laptop with me. Probably only 80% of that time do I have a network connection available. That other 20% of the time, I’ve got my laptop, but if I were using webmail, I wouldn’t have anything to do with it. If our internet connection were down at work, and I needed to get that list of IP ranges I got from my ISP in an email last week, I’d have to run 2 miles down the road to Starbucks, just to snag it into Notepad and run back to enter 12 characters. If I were using Outlook, I could rev it up in offline mode and check out that previously downloaded message easily.
Since I love PHP and web design in general, this makes me wonder… So I have a question for you other web nerds out there. Isn’t there a way we could accomplish this in a thin client interface?
Most Ajax-based thin clients I’ve used have specifically killed all caching of their pages (through meta tags, etc.) to ensure that clients always get the latest data when they click on a javascript-powered link. Couldn’t we do the opposite and harness this caching support in browsers to ensure that emails would be available for a specified period of time after the internet connection was severed?
I’ve never tried this of course, and really can’t think of an easy method for testing it, but theoretically, shouldn’t this be possible? I mean, that’s part of the point behind cached pages, right? There’s got to be a way to accomplish this, even if it’s through some ikky ActiveX control that only works in IE (which would suit Microsoft just fine for OWA)…
Anyone out there reading my blog have more experience with the caching support in modern browsers? Aside from forcing browsers not to cache a page here or there, I’ve never done much with it, so this is all really theoretical…
I’m surprised no one else has commented on this yet.
Why cache a web page? Cache the data. Then use ActiveX or a Firefox extension (or in my ideal world a ’standard’ equivalent of these two) to present it to the user.
Writing code solely for web applications has peaked my interest. It seems that were coding to be done with browsers as the sole platform, standards which would be adhered to would be required to come forth (something which is currently lacking).
I agree. There’s really no cross-browser compatible solution here, unless you were to somehow manually cache an XML file of data, etc. ActiveX would work in IE but not Firefox, and an extension that wrote out a temp file would work in Firefox, but not in IE…
I really don’t have enough experience with Java to know whether it would be able to perform some kind of cross-platform / cross-browser data caching in this context. Even if it could, then you’d be using… well, Java… (there’s some data about this approach using AJAX and Java on Sun’s site here)
It looks like someone else might have had my idea before asking this exact question on Experts Exchange, with no answer. Upon further investigation, it appears I was correct in assuming JavaScripts filesystem functions are horribly neutered. Without signing your code (ugh, rriiiggghhttt…), you won’t be able to use them.
A few Google results seem to indicate that this would be somewhat possible, if you wanted to use VBScript… more Microsoft proprietary nastiness.
I’m really out of ideas at this point, unless the basic browser-integrated caching capabilities can be harnessed to cache an XML file / text file / other file by the browser, but even that doesn’t keep the JavaScript, etc. memory-resident.
I suppose another method to accomplish this would be to distribute your “application” with a stand-alone web server… Microsoft has one (Calypso, Catalyst, something to that effect…) that they ship with a few different products, when a web interface is required. Again, Microsoft nastiness, but I’m sure there’d be a way to do this with Apache and PHP, which is the only realistic approach I can think of. Then, of course, you end up distributing older versions of Apache and PHP, with no software updates. Always a down-side with this approach, isn’t there?
If you are using a true thin client, not a desktop running Citrix, then you have, what – 16 or 32MB of RAM? Where are you going to cache the emails?
Or am I missing something?
I think we may be getting the term ‘thin client’ used in multiple contexts. I suppose historically a ‘thin client’ has been a dumb terminal… All it does is send / receive keystrokes, commands, etc. The actual processing is done by a large mainframe server.
In this instance, we’re referring to a ‘thin client’ in a somewhat similar context. Here we’re talking about a web-based thin client, which is still talking to the (supposedly) big huge powerful web server, which talks to its miriad of other servers, and returns the data.
In this instance, we’re trying to figure out a way to cache something (like an email, or an RSS feed item, something of that nature) so that it can be displayed later in that web-browser, without the need for an internet connection… Basically a web-based equivelant of Outlook (or other similar email client) in “offline” mode… Where there’s no network communication, but previously received data can still be accessed (you can still read your emails, check your calendar, etc. while you have no internet access).
I’m still not really seeing any glowing possibilities… Perhaps with time the light will go off… Or maybe this is indeed why no one has thought about (well, at least mentioned) this problem before: Because there is no solution with the tools existing at our disposal for development…