An article I'd forgotten about...

Something I posted on Advogato 10 years ago...

26 Aug 2000

Microsoft had the right idea, they just haven't figured out where it makes sense yet.

I'm talking about their whole web browser == the OS thing. You don't want to do that on the desktop, your applications are too heavy-duty, they break the browser metaphor, and the security issues are horrid.

But where it does make sense, is in a handheld computer. The applications you run in one of those things are, mostly, well suited to the model of filling out forms and following links.

Take an iPaq, and install a lightweight browser. No javascript or anything applety... it's a purpose-built browser, if you want special behaviour suited to the touchscreen you hardcode it in.

Then add a copy of Apache with a server-side scripting language. Maybe a bunch. I like tcl (NeoWebScript, that is), but something like REXX or Perl or even a VB clone or Javascript would be useful for people who like those.

Build in your address book applications and the like using the web server. As much as possible your user interface for EVERYTHING is through http://localhost/....

You'd want a few extensions to HTML. A mechanism to edit using rich text in entry fields (using an SGML/XML markup, of course, behind the scenes), for example, and a way to deal with large graphical objects that's better than the way things like Terraserver or Mapquest manage it. But mostly you'd do things through the browser.

It just seems like an automatic match. And with cross-database links (and look at critlink for an idea of how to synthesize them if there's not a good anchor already there... perhaps have a special tag in the URL to signify 'search the document for this string'?) you'd get some nifty epiphenomena.

It's almost worth picking up an iPaq running Linux to experiment with the idea...

Apart from the ability to run a local server so you can maintain local state and computation in the background... sometimes you really need to have a server you control on local hardware... this seems to be the way devices are going. The one thing that I really want in a handheld that they're missing is local casual scripting.

How to "fix" HTML5 as a "Flash Killer"...

Here's how to get people to quit wanting Flash and make them go nuts over HTML5. For real.

Take the HTML5 file tree that defines the application.

Pack it up in a tarball. Not a zip file, a tarball, .tar.gz. I'll explain why later.

Give it an extension like ".5app" or ".zap". Something trendy and distinctive. I'm crappy at "trendy and distinctive". But you get the idea.

When this gets downloaded, it gets unpacked and the default.html in the root gets loaded.

It's a tarball, not a zipfile, so this process can be streamed and the default.html can be loaded and run immediately to display a loading screen. This is not possible with zip, because the directory in a zip is at the end.

Add an HTML5 API to let you ask if a file is available, so the loading screen can (a) check to see how far the download has come, and (b) check to see if resources it wants to display are ready yet.

This way people can have their HTML5 apps in a bundle that just works and behaves like flash applets.

Security: the app itself is considered the "site" when it comes to "cross site" requests, cookies, etcetera. That way you can't drop a .zap on a shared site and use it to XSRF it to hell.

I don't have a blog

Actually, my not-a-blog is really at my I/O port.