Desktop Websites

Posted by dave@userland.com, 1/12/01 at 9:03:34 AM.

The Cobalt Qube changed my life 

A couple of summers ago I got a Cobalt Qube as a gift from a good friend, and it changed the way I looked at the Web, software and operating systems. The Qube is a gorgeous blue Linux box, a complete Web and mail server, loaded up with lots of goodies, but it has no keyboard and no screen.

You configure the Qube with a Web browser running on a different machine. For me this was the real magic of the Qube, I had never used a Web browser in place of desktop Control Panels, which is how you configure Windows and Macintosh.

To this day it remains a mystery to me why I like it so much, working in a Web browser seems easy compared to the hunt-and-peck method of finding the right Control Panel and figuring out which widget I have to click on to get the result I want. This idea changed the way I design software, probably forever.

Frontier's browser-based control panel 

We added browser-based configuration in version 6.0 of our Frontier Web content system.

The Frontier Control Panel is Qube-like, meaning it's entirely in the browser, and our users love it.

It's easy to support, the docs are right there. Some people never bring Frontier to the front, they use it entirely through the browser interface.

Then Manila 

Along with the release of Frontier 6.0, in December 1999, we also opened a free site hosting service, EditThisPage.Com, and now we're running more than 20,000 dynamic sites on our servers. The software is entirely browser-based, that's why it's easy, however because it's browser based, as we add more sites, and as the search engines crawl our sites more aggressively, it gets slower, so we have to add more machines. If you're running a free dynamic public Web service, you know exactly the bind we're in. For those of you who aren't, let me explain.

Economics of centralized servers 

We launched the free service before the collapse of the Dot-Com stocks. At the time, our assumption was that if we were successful at building a growing user base, we would be able to follow companies like Geocities and About.Com, and fund the expansion of our service through the public stock market.

Since then the economic tide has turned, and now we're sure that we'll keep losing money until we have to shut down the service. However, not wanting to strand our users and lose their goodwill, we are getting creative. We want to keep them writing and using the Web with our software, but we want to be able to create new software and have a profitable business that makes our shareholders happy.

We're lucky because we have a revenue stream from Frontier, so we can make this transition smoothe, and deliver benefits to users in the process.

Distributing the load 

So we're exploring ways to distribute the load, so that our users' machines can do much of the work, leaving our servers free for new applications that we can base money-making businesses on. That's how I came around to the idea of Desktop Websites, they appear very timely at this stage in the life of the Internet. They offer a way to make systems we developed in the 1990s work in the new post-dotcom decade.

What is a Desktop Website? 

A Desktop Website is a dynamic Web server application intended primarily for use by a person running a Web browser on the same machine. To the user it appears to be nothing more than a website.

How to 

It's easy to set up a Desktop Website for yourself. (If you're a Web developer, you've probably already done it a few times while you work on a site to deploy on a centralized server.) Here's a brief checklist.

Install your favorite Web server software on your desktop machine, it could be Apache, WebSTAR, IIS, whatever, and configure it as if you were setting up a multi-user server. Link in your scripting environment, again, it's your choice, it could be Python, Visual Basic, Perl, Cold Fusion, Tcl, REBOL, you name it.

Install your database, write the config files, and create a Hello World page that displays the clock or a counter, something that changes every time you reload the page.

Visit the page in your Web browser. Its URL is something like http://127.0.0.1/. Refresh.

It's fast, right? Pound on the Refresh button, it never falls behind.

Now go back to your Hello World dynamic page and start writing code, do a calendar, a weblog editor, an inventory system, do your best to make the page slow, and I bet if you're on modern hardware you can't do it.

Connect it to a cloud 

OK, this is great if all you want to do is edit stuff on your desktop, and as I saw with the Qube, that's enough justification to deploy server software on the desktop. If you want to give this to users, work on packaging and installation so they don't have to go through a lot of steps to get one running.

But the real sparks start flying when, behind the HTML interface, the local website communicates with a centralized server using one of the new XML-over-HTTP-based protocols for distributed computing, SOAP or XML-RPC, which in the spirit of disclosure, I must tell you I co-authored the specs for.

XML-based interfaces work better because they are optimized for machine-to-machine communcation. The centralized server, or "cloud" mostly acts as a database, a shared storage system for group applications. It doesn't do any rendering, all that is done on the desktop machine.

So with the same number of machines at the centralized location, you can serve a lot more users. I believe this is the key to creating applications that work without the financial support of a wildly generous stock market.

Let's compete! 

My company, UserLand Software, is working on an integrated Desktop Website environment for Windows and Macintosh called Radio UserLand, but we welcome competition. The idea is too good to keep to ourselves, that's why at every opportunity I'm evangelizing it. I think this is a huge opportunity for Unix platforms and open source scripting environments and databases to make a real contribution at making the Internet run better.

Let's bring the power of the Web right to the users' desktops. The performance is fantastic, they'll appreciate the new features we can add when scaling isn't such a big issue, and as developers, we'll be happier because we'll be able to focus on what we love, developing new stuff, and save a lot of headaches and heartstrain that comes with running centralized servers.