Desktop Servers, Take Two
George Bauer at the Python Desktop Server Weblog graciously responds to my critique of the Desktop Server/Community Server model. First, I want to re-iterate that I think it’s great that someone is creating an open source clone of Radio Userland, and, from what I can tell, improving on it. PyDS claims better performance, and although I’ve never tried it, Radio Userland is a resource hog. More usefully, it appears they’ve done away with the ridiculous 1989-era Compuserve-style assigning of numeric IDs on the Community Server side. Finally, from George’s weblog, it appears they’ve implemented Trackback (which Userland has been struggling with.
However, I do have some feedback/comparisons to the advantages George lists.
- Radio Userland was the model Fair enough. If you’re cloning Radio Userland in open source, you don’t make it a clone of Movable Type (which is already free)
- Distribution of server load. Blogger has problems with server load, because it’s a hosted service. Everybody’s post has to pass through the central Blogger servers. Movable Type is a set of CGI scripts that you install on your own website — hence distributed server load.
- Dynamic rendering handled at the desktop server. Not rendering stuff dynamically from a database. Neither is Blogger or Movable Type. With regard to serving up the weblog pages, rendering is done only at the time of posting. With regard to serving up the interface, the rendering is only being done on demand, but, with Movable Type, because it’s not a centralized service there’s no significant lag.
- Always there in the background, even if you are not connected to the internet. Granted. However, this is the most important reason I chose not to go with a Desktop Server/Community Server system, whether Radio Userland or Python Desktop Server. The side effect of it being there for you, even if you are not connected to the internet, is that it’s only there for you on one machine. If you have Radio/PyDS installed on your home computer, you can’t blog from the office without turning your home box into an always-on, always-connected server. Not only does it defeat the purpose, but it’s simply not an option for those of us with dial-up.
- No need to run another application; the desktop server runs in the browser.Same for Blogger and Movable Type. Except they run in the browser on any computer on the planet, not just the box the Desktop Server is installed on.
- Interface is simple to build and extend. Same for Movable Type. Blogger hasn’t exposed their core code, but Movable Type has a robust plug-in community.
- The architecture allows easy remote access via HTTP to your home machine. Ummm…try that if you access your home machine via dial-up. Try installing it on a work machine behind a firewall where that “easy HTTP access” consitutes a violation of the corporate IT policy. Not so easy anymore. See #4 above.
Blogger has traditionally suffered from being a fully centralized (and underfunded) service, but that seems to be going away since they have Google’s resources behind them now. Movable Type doesn’t have any community or centralized component to it; you run the application on your own web server (or hosted web site). There are no sharing of resources. However, it’s not the best choice for someone who (a) doesn’t have a web hosting option that supports CGI applications or (b) has no technical skills.
Python Desktop Server/Community Server, along with Radio Userland/Radio Community Server, divide the tasks between a local client and a centralized community server. The drawback here (and George didn’t really address this) is that to be able to blog from anywhere, not just the machine that hosts the client, you basically have to turn the client machine into a server anyway. At that point, why not just “host” the PyDS application on a web server, instead of on a local client?
Desktop Servers, Take Two
Ok, Greg comes back to my reply to his posting regarding the usefullness of the concept of desktop servers. Since I think it’s quite cool to have a discussion running on two different weblogs (and it might even raise my technorati ranking Image: …
Just a note — I run PyDS on two machines. You can backup and restore as you go remote. At the cost of being a bit disciplined about PyDS startup/shutdown (always backup first), I avoid the home server connection issue. (A Tk tool to simplify this is on my to-do list.)
The primary reason I do this is to keep the aggregator in sync between the two instances. (Which I think you listed as a desired feature.)
It works great — I’m at a conference, and get to keep my reading up to date during the boring parts :)
Just a note — I run PyDS on two machines. You can backup and restore as you go remote. At the cost of being a bit disciplined about PyDS startup/shutdown (always backup first), I avoid the home server connection issue. (A Tk tool to simplify this is on my to-do list.)
The primary reason I do this is to keep the aggregator in sync between the two instances. (Which I think you listed as a desired feature.)
It works great — I’m at a conference, and get to keep my reading up to date during the boring parts :)