Archive for the ‘APIs’ Category

The mystique of desktop web servers

Q: What is a desktop web server?

I guess it should be no mystery, it’s a web server that runs on your desktop.

Q: What makes a desktop web server different from one that runs on a server?

Not much. You could run Apache on your desktop. In fact, if you’re using a Mac, you are. When the time came for Apple engineers to decide to turn off the server, they thought, what the heck, let’s leave it on and see what happens. Unless I’m missing something, so far not much has, but it could.

Now let’s zoom back to 1998. I want to explain a decision I made in January of that year. We had almost completed the port of Frontier from the Macintosh to Windows. I was using the Windows version. We still we had to recreate a networking layer that would do for us on Windows what Apple’s networking, AppleTalk, was doing on the Mac. We could have used Microsoft’s proprietary networking, it was called COM, but since I already saw myself as an Internet developer, instead I wanted to use the Internet to connect my computers.

This had several important advantages.

1. I could connect my Macs and Windows machines using the same protocol.

2. Since there is no platform vendor for the Internet, they couldn’t break us, like commercial platform vendors always do. Read the thread on Apple’s latest RSS crap to get an idea how that works. Even if they’re well-intentioned, they still don’t care about the little guys, you know, like you and me. ;->

3. I could connect to Unix machines for free.

4. I could connect to anything that comes along later.

5. I could connect computers that were very far apart, since the Internet is a world-wide network.

Those are all pretty compelling reasons, so I announced my intentions and went ahead and it happened incredibly quickly, we created a new networking layer, and not only was it quite useful for our users, it went on to become one of the biggest defacto standards of the Internet, almost as big as RSS, but not quite so visible (since it’s really plumbing and largely of interest to developers although users like what they do with it).

Anyway, there was another reason this approach was cool, because it built on XML and HTTP, we got a web server for free. And thus was born UserLand’s web server. It’s built into Frontier, Radio and the OPML Editor. Every time you install one of these programs, you get a web server. People use it all the time, but they’re probably not even thinking about it, and most of them aren’t even aware of it.

This really came home to me in a conversation with Mike Arrington yesterday. I was trying to explain the Aggregator API that was released yesterday. He didn’t understand that there was a web server in there, and that you could put an API on it even if it’s running on the desktop. Why not, a lot of APIs are running on the desktop (that’s largely what Windows is).

I told Mike that it didn’t matter where I ran the software. Most people ran it on the desktop, but you could put a copy of the OPML Editor on a server and access the aggregator from afar. I guess it’s a very new idea (even though it’s already 8 years old) that you can use the protocols of the Internet to connect two apps that run on the desktop, but you can, we do it all the time. It’s very general, and quite powerful, and flexible.

  The Internet is not just a world-wide network, it’s also a local area network, and it’s can be an inter-application communication protocol, for two programs running on the same machine. The same simple protocol can be used in all these contexts.

To prove the point, I put a copy of the NewsRiver aggregator on a server of mine in Massachusetts that I’ve never actually seen. It’s definitely not running on my desktop. Here’s a link to the aggregator running on that computer. Go ahead and try it out.

Note, this link may not work tomorrow or the day after. ;->

PS: Another example of desktop web servers, Google’s desktop search. You access it through a web browser, but the software is running on your computer. Ever stop and think how that happened? It’s so simple people don’t even notice.

PPS: I wrote a piece that attempted to define desktop web servers at the beginning of 2001. I thought that would be the year of DTWS’s. It wasn’t. We still haven’t had an explosion of creativity in this area, but I think there’s still reason to believe we’ll see it, eventually.

PPPS: I wrote a piece in 1998 that explained in fairly non-technical terms how APIs work. Anyone trying to understand the basic concepts of what we now call Web 2.0 should master these concepts or else you’re just talking marketing BS. Maybe you already understand APIs, if so, good for you! But if you’re still scratching your head, the concepts really aren’t all that hard.

Links to docs for the Aggregator API

This post tries to tie together all the bits in the release of the Aggregator API, and provides a place for developers to comment, ask for help, report problems, etc.

For background, read this post on Scripting News today.

If you have the OPML Editor running, you should install the latest version of newsRiver.root, and fully update it according to the instructions on this page.

Once you’re up to date, you can run two sample scripts, by jumping to:


If you don’t have the editor running you can view the source for these scripts.

The docs for the API are on the XML-RPC site.

Just for fun, I put up a NewsRiver that you can use over the web.

I’m thinking about whether or not I should let people run the API against this installation. You can delete aggregator items this way. You can delete all the items. Not that I care, but it might make it hard for more than one developer to test against it at a time.

If more information becomes available I’ll link to it here.