Except that my web server already has ASP.net. I get a few hundred hits a day. What do I care? :-) I understand what motivates someone like Dave to make it just require FTP and no active server components. He has a monetary interest in working with the largest crowd possible. Personally, I don't have any such need. I'd rather prefer something powerful and dynamic over something static and flaky, but that's just me. :-) [The .NET Guy]

You're right. That's the only real difference between a power user and a typical end user. So it's just a question of target audience.

Technically, most of the code could be shared with the decision of when the content is generated being the only thing done differently. Obviously the content generation engine and database manipualation could be the same. It's just a matter of when the content engine is executed and what is done with the results. In the "desktop publishing" scenario it's executed for all posts, over all categories, each time a new post is published. In the "on demand" scenario, there's some sort of timestamp kept in the database that the IHttpHandler would check against the date of the file on the system (if it even existed) to determine if it needs to be regenerated.

Just some thoughts... maybe one day one of us will actually find the time to put this thing together. ;)

What I want is dynamic page generation, so if I change something in one of my headers, etc., I don't need to re-generate and re-publish every single page on my site.  Since the FTP upload of Radio is a little flaky for me, this is a killer.  To add to that, Radio actually re-publishes every page in your site when you add a new article on a new day, so it can re-generate the calendar on each page.  Adds to my FTP problem. [Greg Reinacker's Weblog]

I'll echo your experiences with the FTP support in Radio. The FTP support in CityDesk is much better, but of course is still a manual system. Like you, I'd prefer something that leveraged that ASP.net runtime so that publishing is a simpler and more foolproof. I'm just about convinced that the right way to do it is to have whatever tool you're using generate XML files that get shoved up to the server, and then use ASP.net to walk through them as necessary. [The .NET Guy]

Well, that sort of defeats the whole idea behind content generation and publishing, doesn't it? The whole power of Radio is that it's "desktop publishing". Your server doesn't need to be anything except a dumb HTTP server that supports the GET protocol basically. The idea is that, like in a database, writes occur a lot less than reads. So yeah, all the content is regenerated on a publish, but is static for the N reads that follow it on the web site.

So what could a more dynamic alternative be? Run some kind of application (ASP.NET based obviously) on the webserver which reads from a database which you update from your desktop via SOAP calls. Then, content could be cached by the built-in caching framework, but you'd need a custom expiration scheme. Also it would all be cached in memory which is hardly as scalable as caching it to disk. So you would probably want a custom architecture, done with HttpModules most likely, that detects whether or not the requested URL's content has been built since the last save and if not, build it on demand and save for future requests.

[Macro error: The file "C:\Program Files\Radio UserLand\www\#prefs.txt" wasn't found.]

Ok, great. Where'd it go? I know I didn't delete it and I haven't even posted anything in a couple days. It only happens when I try to put a title on my posts. *sigh*

Update: I went to the folder, saw that #prefs.txt was in fact still there, so I opened it in notepad and just saved it (as is) and everything works again. Interesting.