Drew Marsh: Drew's Blog::Blogging

Radio Dies Again

Fri, 31 Jan 2003 02:23:59 GMT

This time my worskspace.pt table was missing.

Heads Up: Sam Gentile Has Moved His Weblog

Thu, 30 Jan 2003 18:45:32 GMT

Ok, I've had it with Radio and its many bugs, lack of updates, quirks, etc. This is not anything new. I have wanted to move for a very long time to something .NET based but I have not had the time. Scott Watermasysk has graciously volunteered access to his ASP.NET solution and hosting. So I am moving. My new site will be here. The new RSS feed is here. It will take some time to move over and get things squared away especially with project and book deadlines, and a new baby so please be patient with me. I hope all my loyal readers will continue to read at the new site and as always, I thank each and every one of you for reading my stuff and hope that it continues to help you in youyr work. [Sam Gentile's Weblog]

Hmm... I might have to try this out myself.

Simon's Radio Pingback Client: A Small Code Review

Sat, 18 Jan 2003 23:38:17 GMT

So, I'm sitting here doing a database upgrade and while I was waiting for a ton of data to finish replicating I was looking over the implementation of Simon's PingBack Client for Radio and noticed that in his pingbackSuite.checkPost method he has a support function called extractLinks that does a lot of manual string parsing that could very easily be replaced with some Regex calls. Radio has Regex support via system.extensions.regex. In that library there is an extract method. The regex to find the links would be <a .*?href="?([^">\s]*). Therefore, extractLinks could be rewritten simply like so:

on extractLinks(txtWP) local(txt = string(txtWP)) local(linkMatches = nil) // Extract the matches, specifying the list returned contain only the URL group regex.extract("<a .*?href=\"?([^\">\\s]*)", @txt, @linkMatches, { 1 }) return(linkMatches)

Nothin' major, but why write all that annoying parsing logic yourself, ya' know? :)

Item Titles Not Rendered On Category Specific Pages In Radio

Fri, 17 Jan 2003 18:40:32 GMT

Riddle me thiis grasshopper. Why do titles that have been set in Radio and inserted manually into the Item Template not show up on any category pages even if they use the same exact template? [Sam Gentile's Weblog]

Excellent observation Sam. Time to dive into the publishing code.

Update: Just got the chance to look into this, then I remembered that categories have their own independant templates. So you actually need to go into <Radio Program Files Root>\www\categories\<Your Category> and update the templates there to inclue <%itemTitle%>. You can probably just copy your itemTemplate from the main site since you pretty much want the same look and feel across categories in that respect.

Update 2: Apparently you can just nuke the templates from the category sub-directories and they'll be rendered using the templates from the main directory. Makes sense if you wanted to control each category's rendering independently.

Radio's News Aggregator and RSS (Part 2)

Thu, 16 Jan 2003 19:56:49 GMT

Ok, so I was partly wrong. After wading through the process of reading a news feed and turning it into a story, it turns out that in the presense of an RSS title it is concatenated onto the front of the storytext member of the story datatype. Here's the code from system.verbs.builtins.xml.rss.compileService:

if sizeof (title) > 0 if sizeof (link) > 0 s = "<a href=\"" + link + "">" + title + "</a>" else s = title

That is then concatenated with the RSS description text node and set as the title member (a weird name considering it's a lot more than a title) of an item data type (the adritem variable in the code). Then in system.verbs.builtin.xml.aggregator.storyArrivedCallback this item is translated into a story type and stored.

Really, I'm guessing most of this is legacy. I'd really like to have more fine grain access to each piece of an incoming item so I can render it differently on the news page. However, this would appear to require drastic changes to the way news is currently processed in Radio. It's not that it can't be done, but it would require a lot of work on system modules.

Radio's News Aggregator Sorely Lacking In The RSS Department

Thu, 16 Jan 2003 18:49:32 GMT

Sadly, upon further investigation, it's not just a problem with the RSS title being rendered, it's a problem with it even being collected! The news is stored in a file called aggregatorData. If you open Radio and jump to this address (CTRL+J) you'll see a table called stories. Each one of these "stories" is apparently the Radio native equivalent of an RSS item. The only available properties of a story are:

channeltitle: the title of the channel from which this story came (/rss/channel/title)
storytext: the content of the story (/rss/channel/item/description)
time: time the story was processed and entered into the database (NOT /rss/channel/item/pubDate)
url: link to the actual story (/rss/channel/item/link)

So we're missing a ton of RSS data here. That said, all the RSS data *is* available and stored in aggregatorData.services.[urlOfRssFeed]. So now the trick is to find where the RSS data is translated into a Radio story and augment the recording process from there.

Radio's News Aggregator Doesn't Render RSS Titles

Thu, 16 Jan 2003 18:17:55 GMT

After the previous post, I realized something I never noticed before: Radio's built in news aggregator doesn't render item titles! No wonder a lot of Radio user's don't use the title feature, it has no benefit to Radio's own aggregator.

I'm looking at the code right now, which is in system.verbs.builtins.radio.html.viewNewsItems, and they don't even try to pull titles out of the RSS items. How bizzare. I'm going to edit my copy, but I've also suggested to UserLand that they add this in their next Radio.root update.

RSS Titles In Radio

Thu, 16 Jan 2003 17:34:00 GMT

Radio Titles. Anil John: I for one DO use the Title option that Radio provides [Sam Ruby]

As do I, but the problem is I have to repeat it in my content. I suppose I could edit my item template to emit the title for me with <%itemTitle%>. Hmmm... then all my existing posts where I've included the title in the content would be doubled and I'd need to go back through them and remove the repeated title from the content. I might just do that though.

RFC: RSS 2.0 and the MetaWeblog API

Mon, 13 Jan 2003 19:55:10 GMT

RFC: RSS 2.0 and the MetaWeblog API [Scripting News]

Ugh, holy hacking batman. The more XMLRPC gets put to the test, the more is shows just how weak it really is. It's only based on simple well-formed XML, so that's as far as it can go without hacking things like this:

If you wish to transmit an element that is part of a namespace include a sub-struct in the struct passed to newPost and editPost whose name is the URL that specifies the namespace. The sub-element(s) of the struct are the value(s) from the namespace that you wish to transmit.

Wow... nasty. :\

This would be an absolute XML no-brainer in SOAP. Perhaps it's time to work on a SOAP based weblogging API.

MetaWeblog API Mailing List

Fri, 10 Jan 2003 17:54:36 GMT

A new mail list for the MetaWeblog API [Scripting News]

Dave's started a mailing list for those interested in discussing the MetaWeblog API.

Pingback Test

Thu, 09 Jan 2003 20:59:16 GMT

pingback. The v0.3 pingback client for Radio is now available, it now fully implements the auto-discovery aspects and also spawns off a new thread to do the pingback work, so as not to slow down upstreaming. [Simon Fell]

I just installed Simon's Pingback client for Radio, this is just a test to see if it works. If it does, this should send a pingback request for this post (#944). Here's his current server implementation that displays the pings.

Update: Sure enough, it works! Great stuff Simon.

Blogger API Wars: Mind the FUD

Thu, 09 Jan 2003 15:50:49 GMT

... The naming is unfortunate because Pyra is radically changing the Blogger API, breaking everyone who implemented it. Presumably someday the pages describing the API will disappear. We should do a backup and a rename, those of us who plan to continue to support it, regardless of what Pyra does. I wish we could convince them to tread more lightly. Perhaps the best thing to do is to fill in the MetaWeblog API, with docs for the entry-points that are currently documented on the Blogger site. We'll get through this. It's a fairly broadly supported API, despite Pyra's disclaimer. [Scripting News]

Uhh... this smells like a serious FUD spreading attempt to me. First off, they're not breaking anything. All Blogger2 API XMLRPC calls are prefixed by "blogger2." instead of "blogger.", so there's no breaking going on at all. Also, just because Pyra is coming out with the Blogger2 API doesn't mean they're going to stop supporting the Blogger1 API. Nor are they expecting the entire world to switch. If they do stop supporting the Blogger1 API that's really only going to hurt their customers and, if they want to do that, that's their decision. Personally, I think the new API feels a lot cleaner, albeit there are some things that still need some ironing out. The important thing is that it's still in the RFC stages, so if you have a problem with it you should be contributin g feedback now.

IMVHO, the real problem is that these APIs are layered on top of XMLRPC. Had they been layered on a more strongly typed protocol (i.e. SOAP) we wouldn't even have needed the MetaWeblog API. The major differences between the Blogger 1.0 API and the MetaWeblog API are the concept of what data makes up a post. Why should we need a completely different set of publishing/editing methods just because the details of a post in each has a different shape?? Had SOAP been used, we could have typed the post parameter using a namespace and the backend could have determined whether or not it was capable of handling content from that namespace. This would have immediately allowed us to go from a simple text only post to an XHTML post to rich RSS 2.0 posts including titles, links, etc. Really, it could accept any type from any namespace and, as long as the server supported it, there would be no problem. Another nasty bit of the APIs is that you always have to pass application key, userName and password to each method. Not only does this clutter the meaning of the method, but in some of the APIs the order of the parameters varies!!! How about a little consistency?? Had SOAP been used, these details would simply be SOAP headers and wouldn't clutter each specific method signature. 20/20 hindsight I guess, but I can't understand why any APIs being invented now aren't taking these things into consideration.

Finally, I agree that updating the documentation for the Blogger1 and MetaWeblog APIs in a single place is a great idea. Some of the Blogger1 APIs aren't even doc'd in a single place (i.e. blogger.getRecentPosts, blogger.deletePost), same with MetaWeblog though (i.e. metaWeblog.getRecentPosts, )... nevermind both. I've had to scour all over to fill in the complete APIs and that's just not a good way to promote third party development which is what exposing these standard APIs is all about.

Blogger API Differences in Blogger/Radio (Part 2)

Wed, 08 Jan 2003 20:31:09 GMT

Ok, so I tracked down the problem in Radio and made a simple change to the script responsible for generating the response to getUsersBlogs. It's located in system.verbs.builtins.radio.weblog.bloggerApi.rpcHandlers. Basically, you just need to change this line:

t.blogname = encode (adrblog^.prefs.title)

To this:

t.blogName = encode (adrblog^.prefs.title)

A UserLand representitive has responded to my bug report in their forums and hopefully they will make a patch to Radio.root that will fix this for users so that Radio is truly compliant with the Blogger API.

Blogger API Differences in Blogger/Radio

Wed, 08 Jan 2003 15:57:28 GMT

Case Sensistivity in XML-RPC. Drew Marsh emailed me about some discrepancies between the Blogger and Radio impementations of the Blogger API. It seems that.... [Cook Computing]

So, I'm toying around writing a Weblog client. I've created an abstract connection/weblog/post model which would then have strongly typed connection classes per protocol. I've started with the Blogger 1.0 API which is layered on the XMLRPC protocol since it's basically the bare minimum that Blogger and Radio support. Immediately, I run into a problem: Radio's implementation uses different casing for some of it's struct members than Blogger. For example, here's a weblog struct from a response to getUsersBlogs:

Blogger's Response:

<struct>
<member>
    <name>isAdmin</name>
    <value><boolean>1</boolean></value>
</member>
<member>
    <name>url</name>
    <value>http://drub0y.blogspot.com </value>
</member>
<member>
    <name>blogid</name>
    <value>3372021</value>
</member>
<member>
    <name>lastPublished</name>
    <value>
      <dateTime.iso8601>20020422T09:58:58</dateTime.iso8601>
    </value>
</member>
<member>
    <name>showTitle</name>
    <value><boolean>0</boolean></value>
</member>
<member>
    <name>blogName</name>
    <value>Drew's Blog</value>
</member>
</struct>

Radio's Response:

<struct>
<member>
    <name>blogid</name>
    <value>home</value>
</member>
<member>
    <name>blogname</name>
    <value>Drew's Blog</value>
</member>
<member>
    <name>url</name>
    <value>http://radio.weblogs.com/0104813/ </value>
</member>
</struct>

Now, the problem is, Radio uses "blogname" where Blogger uses "blogName". I consider this to be Radio's problem since Blogger defined the API and their definition of the weblog struct uses the mixed case version: "blogName".

The whole reason I had to write Charles is because I couldn't believe that Dave Winer, the XMLRPC inventer and the one who implemented the Blogger API for Radio would make such a mistake. Furthermore, how, after almost a year now, does nobody else pick up on this? So I thought perhaps XMLRPC struct members were intended to be case-insensitive and there was a potential bug in XMLRPC.NET. I looked and looked and no where do I find concrete information about casing rules. I've read many things about the tags being case-sensitive, but that's a given considering it's just XML.

So, if the answer is indeed that struct member names in XMLRPC are case-sensitive (which would make the most sense) then the bug lies in the Radio implementation of the Blogger API. I guess my next step is to venture into the Radio forums to report the bug.

XML-RPC.NET v0.7.0 Delivered

Mon, 06 Jan 2003 14:26:17 GMT

XML-RPC.NET v0.7.0. I've just uploaded version 0.7.0 of XML-RPC.NET. Its available here. The changes/fixes in this release are: error reporting of parsing...... [Cook Computing]

I'm pretty sure anyone who has to work with XML-RPC in .NET uses Charles' implementation. I've been using it lately to implement a blogging client capable of talking to any server implementation that speaks Blogger 1.0. The Blogger 2.0 API is currently in the RFC stages and while I've offered what I think it some decent feedback on a couple of issues via the bloggerDev mailing list, I haven't really gotten much of a response (yet).

Radio Strikes Again

Tue, 05 Nov 2002 01:43:26 GMT

Ok, I don't know why it's working all of a sudden, but it is. For the past few days I haven't been able to post anything because Radio complained about not being able to read one of my data files due to an "incompatible version" or something like that. I have no clue why it started, but Radio hadn't been shutting down cleanly for about a week so I figure that had something to do with it. Its bound to happen again, so I'm starting to backup all my posts to XML in case I need to bail out of Radio and start using other blogging software. It seems like a lot of people are doing that these days...

Ethan Brown Joins the Community

Wed, 23 Oct 2002 16:35:12 GMT

Ethan Brown has started a blog. Welcome, and subscribed. [The .NET Guy]

Welcome Ethan! I don't know Ethan personally, but he's a familiar name on many of the mainling lists to which I've subscribed over the years. RSS subscribed.

Changing Themes

Thu, 17 Oct 2002 19:58:20 GMT

Bear with me while I change to a new theme. I wanted to go with something simpler/cleaner. I thought this template would be a good jumping off point, but I still need to XHTML'ize it and hand tweak some of the CSS.

Don Box on Blogging and RSS

Wed, 10 Jul 2002 22:27:06 GMT

Don made an awesome observation about the ties between blogging and RSS. This little snippet pretty much sums it up:

while (true) {
ScanRSSFeeds();
RantAboutStuffYouSawFromRSSFeeds();
ExposeYourRantsViaRSS();
}

What an amazingly virtuous cycle!

Blogchalking

Tue, 09 Jul 2002 23:57:48 GMT

I saw Brad did this and thought it was a cool idea, so here goes:

Google! DayPop! This is my blogchalk: English, United States, New York City, Greenwich Village, Drew, Male, 21-25!

Now to add meta tag and icon on the page...

.NET Blogging Tool Saga Cont'd - Part 2

Tue, 02 Jul 2002 23:42:50 GMT

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. ;)

.NET Blogging Tool Saga Cont'd

Tue, 02 Jul 2002 21:45:36 GMT

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.

Radio Blow'd Up

Tue, 02 Jul 2002 16:44:58 GMT

[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.

Bit Again By Radio Title Encoding (Or Lack There Of)

Wed, 26 Jun 2002 16:26:49 GMT

Thanks to John St. Clair who pointed out that my RSS feed was trashed again. This time it was due to the '&' in the Don Box & Inclusion post. Even after I pointed this bug out the previous day, I fell victim to it again. *sigh* Is it too much to ask for proper encoding/decoding in the next Radio root update? Pretty please?

Warning: Radio Doesn't Encode Post Titles

Mon, 24 Jun 2002 20:37:53 GMT

Just a heads up for anyone else who hasn't already discovered this. Radio does not encode the title supplied for a blog entry. This means that if it contains any illegal XML characters such as < or > your entire RSS feed will be screwed. Thanks to Andy McMullan for pointing this out! Andy discovered the problem when his aggrgegator barfed on parsing the RSS.