|
Thursday, April 10, 2003 |
|
After going down a painfully wrong path, a very quick answer from one of the developer's (the developer?) of PyCS pointed out how incredibly easy it is to switch from www.weblogs.com to www.pycs.net as your Radio hosting server. Just a matter of setting the community server in the appropriate Radio page (link will only work if you have Radio running). Later, I'll post a step by step set of instructions, including how to upstream the redirect to the old site without requiring you to temporarily maintain two separate Radio installations.
Thanks to Jim Roepcke for helping me out on that last bit.... |
|
2 Days until Radio goes dead... ... and I ask: What do I need in a blogging tool? As many have pointed out, it is the Radio-- the application-- isn't expiring in two days. My ability to publishing to the weblogs.com radio community server is what is expiring. Problem is; the Radio Community Server is really the only part of Radio Userland that is of value to me. As a desktop web server, Radio is not a good solution in that it tends to consume lots of system resources on a regular basis for no apparent reason (as I have everything turned off). Radio's news aggregator is sub-optimal in comparison to such a wonderful tool as NetNewsWire and the WebLog post editor in Radio suffers from being a form on a web page. It simply can't compare to, say, this (NNW Pro). Furthermore, the Radio application locks you into one location in the filesystem -- move the app directory, and your blog dies until you fix it (very hard) -- and it freely mixes user data with the application itself. Very old school macintosh. There is a lot to like about Radio. Namely, Radio provides a dead simple entry point into the world of blogging. Download the app, answer a couple of questions and you are sharing your thoughts with the world. It has served me well in that regard. But now I want some more control in a system that has a more modern implementation. As I mentioned previously, I'd really like something implemented in Python simply because I know the language well and it is very easy to customize an even half assed implementation written in Python. That goofy whitespace based scoping ensures that it is basically impossible to write code that an experienced Python programmer cannot grok unless you are also an experienced Python programmer. But experienced python programmers already know that there is zero value in writing ungrokable code. But, in reality, language of implementation is completely irrelevant. It isn't like I have such an amazing surplus of time on my hands that I'm going to be able to futz around with modifying some random blogging engine to do something different. So, what features do I need (and what don't I need)? Desktop Web Server -- already have one. It is called Personal Web Sharing and it comes with ever installation of OS X. Better yet, clicking the "Start" button for Web Sharing turns on an Apache based, totally standard, web server and advertises my machine's web server via Rendezvous onto the local area network. Desktop Web Server on Steroids -- certainly don't need one in the blogging tool. Or maybe I do, but for all the wrong reasons (see below -- after the inventory of solutions). Hosting -- this is the big issue. Where do I host the content once it has been written? It needs to be somewhere that Google indexes because I have found that I use my weblog to take notes about various random useful or cool things that I run into / figure out / discover. If I need to refer to something from anywhere in the world, it is a simple matter of sticking a search string in Google with "bbum" or "bbum radio" prepended to it. I could host it at .mac, but then I don't have .... Referer Logs -- Since I starting to publish via Radio, the referer log has proven to be far more value than simply as a means of quantifying my personal ego inflation. By keeping an eye on the referer log, I have been able to tell what subjects are of interest to the community, what keywords tend to draw the most traffic from searches, and who has excerpted chunks of my entries with back pointers. The latter is the most interesting in that it often leads to blogversations; I'll excerpt and comment on something from one person, they will respond in kind on their blog to my entry, a third party will jump in with excerpts from both. In the end a network of inter-related posts can be followed to see how a particular meme evolved or idea was refined. Editing/Publishing -- A total non-issue. There are so many wonderful tools out there for editing blog posts. Not that editing a blog post is rocket science; after all, it is just an HTML fragment. As mentioned above, I'm using NNW's WebLog editor -- works very well. Maybe some day, I'll revive RadioService (with a new name because it was never about just posting to your Radio Desktop). I have a potential mind bomb that I'd love to drop on the world some day. Templates that make sense -- Radio actually has a decent set of templates, they just aren't managed very well within the application. Templates are the basic building blocks for the ultimate "rendered" form of one's weblog. A true templating system really has nothing to do with HTML compliance, CSS, or-- even-- HTML related content. It is simply a bunch of components that have labeled holes throughout into which your custom content is dropped. Obviously, it is a bit more complex than that statement might imply. The thing that compiles the custom content + the templates into the eventual published content must be able to deal with stuff like calendars, table of contents, and other fun, relatively compute intensive, features. Funky Caching is a neat idea, but completely useless for my needs-- I want all the content to be available all the time because I want it to be indexed by Google! Access to prior Content -- Two kinds of access; access for the purpose of creating backups and access for the purpose of referring to and editing prior items. News Aggregator -- Nope. Don't need that. I have Net News Wire and it does a perfectly fine job. RSS Generation -- Yup. Need that. It is just a special case of content generation and every blogging tool should do it and do it right. So -- what are the possibilities? For each, I'm considering what problems it solves and lumping everything into two categories. Something listed here solves one or both of Hosting or Content Production/Management. Some things do other stuff. Some things inter-operate in one direction or another. It is very confusing. This is in no particular order. This is not intended to be a complete list of everything out there -- just a collection of random things that folks were kind enough to point me to or things I have stumbled across on my own.
In actually going through the process of typing all this up -- of giving a brief evaluation of each potential [partial] solution-- it dawned on me that the reason why Desktop Web Servers come up in the context of weblog tools is that the rendering the content for a weblog is actually somewhat complex. It requires dealing with time series based raw data (the entries) that may have "holes"-- days, weeks, or even months that completely lack entries. Yet the rendering system has to deal gracefully with these holes when creating navigation elements such as the ubiquitous calendar. In other words, the "front end" -- be it a form in a web page, a tool like NNW's weblog editor that posts via a "standard protocol", or a desktop application-- pushes a raw chunk of data into the "back end". The "back end" then takes this chunk of data and figures out what needs to be rendered (or re-rendered) as a result. In the case, of PyCS/RCS compliant systems, the "back end" then pushes the changes to the PyC/RC server. For all intents and purposes, the "desktop webserver" used in PyDS, Radio and other similar tools is basically just a calculation engine with an HTTP UI. That it uses HTTP is irrelevant save for tools that also provide some kind of a "desktop webserver" control panel via that same HTTP channel (as does Radio -- which also provides an aggregator through that same channel). It isn't the desktop webserver that matters, it is the solution's ability to do that complex rendering on the fly. Radio and-- I would assume, I haven't looked-- PyDS use the desktop webserver as a background process that does the rendering and pushing of content out to the actual servers. It could just as easily be done within a front end application. The presence of a desktop webserver merely implies that the rendering & push features exist in some potentially automated fashion. Some of the other solutions listed above either push that rendering/publishing functionality to the server (MovableType, Conversant, others) and some push it into the client desktop application (iBlog). Others seem to kind of lump it all together into a single manual task; you create an entry, you run a tool to 'post' the entry, that tool also recompiles the content as appropriate. For the moment, I think I'm going to take the easy way out and see if I can't stream my Radio desktop server's content to the PyCS server. That'll buy me some time to write the [very short] Python script necessary to suck everything out of Radio via XML-RPC and push it into whatever other solution I end up moving to. We'll see how far I get.... I wanted to thank everyone who took the time to write me with suggestions as to how to solve my stated problem. Someday, I'll try to respond to each person individually-- but that is unlikely. There is an awful lot going on right now. Please forgive me if I don't personally thank you-- you'll deserve it. It is greatly appreciated.
Sheesh. That may be my single longest Radio post ever. |
Last update: 1/5/04; 9:40:29 AM .
