inessential by Brent Simmons

2001/01/18

Radio's Web server

One of the things we've been working on is figuring out what do with the dual nature of Radio's Web server.

It does two main things:

1. File serving. Any files you put in the www folder are available to the rest of the world.

2. Desktop websites. These are applications like My UserLand on the Desktop. In this case you can read and route news, maintain a weblog, and so on. It's a website where you go to work.

In the first case, files are simply served from disk. In the second case, a database contains scripts, templates, and data that implement an application.

So, the question is, what's the top level? What do you get when you request http://127.0.0.1/? Do you get the top level of the www folder, or do you get a desktop website?

Answer: the top level is the top level of your www folder. If you go to http://127.0.0.1/, you get the index.html file stored in your www folder.

To get to your desktop website, you'd go to http://127.0.0.1/userland/.

The counter-argument to that went like this: if Radio is a desktop website server, then shouldn't the top level be the desktop website? What if I'm at an Internet café, and I want to access my desktop website remotely -- should I have to remember the longer URL?

The solution came to us when we thought about other developers doing desktop websites. What if the folks at Pyra wanted to do a Blogger on the Desktop? What would the URL of that website be?

It would be http://127.0.0.1/blogger/.

This puts our desktop website on an equal footing with other desktop websites. Imagine a future where there are lots of desktop websites in Radio. UserLand's is just one of many. Were I a desktop website developer, I would like that.

Other things I'd like as a developer: this environment has what I'd need -- XML, XML-RPC, SOAP, RSS, HTTP client and server, templates, macros, an outliner, an object database, and so on. Perhaps best of all is that there's no need to run and maintain a server -- it's Radio that is the server. The action is on your users' workstations. The data is on the workstation. What happens to your scaling issues when you the developer don't have to run a central server? Good things.

And as a user, I'd want the choice. Maybe I don't really like UserLand's or Pyra's desktop website -- but perhaps John VanDyk has developed a website that's the bee's knees. I'd have the choice.

More Frontier and Radio Tips for Developers

I got good feedback on the previous tips, so I'll continue. (Plus, it's fun for me.)

Here's a tip: don't over-abstract.

{includeMessage (1219, flDgLink:false)}

Another tip: beware the with statement.

{includeMessage (1218, flDgLink:false)}