The most important RSS element: <title>. Jon Udell has said it before, today Dave Winer says "Unless the RSS has a <title> element, it's going to be kind of goofy". And here I sit, blogging via email to Radio, creating yet another RSS item without a title. I usually try to fix it when I get home; I hate it when other bloggers don't use titles. Forget about the aggregator on the Start menu. How about putting title support into mail-to-weblog? Just look for emails that start with a <title> element, extract that and make that the title of the post. Come to think of it, Sam Ruby's idea to create a weblog API that simply accepts RSS items makes more and more sense.

[Later] As promised, I've titled this entry.  Of course, Sam Ruby has already linked to this post, so everybody's read it and gone.  Wait!  Come back!  After I hit send, I realized that I missed out on some points I wanted to make.  First of all, the lack of titles is clearly a problem that every aggregator has to deal with.  I've used early versions of 4 different aggregators, and every time, the author has to figure out how to handle posts missing the title.   Furthermore, an aggregator that displays just the title and link is probably more useful than one that displays the full content, especially with feeds that truncate the content.  I can think of only a few feeds that work well with truncated content: Phil Windley's, Dare's and Joel Spolsky's.  I believe Phil's works by taking only the first <p> from the post, the K5 diaries seem to have a place to specify an abstract, which is what gets put into RSS, and Joel uses CityDesk, which uses the abstract from the article.  I get really annoyed by feeds that truncate content arbitrarily.  They may as well just pick a good, intriguing title and provide a link to the content, rather than generate a few words. 

There was a link over at codaland to three-legged pi, where the author makes the point "I will always prefer a holistic viewing experience whenever the author has carefully prepared the exact way in which he intends me to view his website."  Again, this is absolutely a valid point.  People like me barely care about presentation (and it shows!), but for sites that are about more than text, RSS is there only to tell readers that there's something new.  In this case, a title and link would be best, though I believe that's the responsibility of the author to produce this kind of RSS, it's not the responsibility of the aggregator to figure out.

Finally, I want to address what James Robertson brought up.  First of all, though I believe Sam was proposing a SOAP interface, I don't see why it couldn't be implemented using regular straight HTTP, whether or not you submit in a URL encoded form, or a PUT, or a POST with a plain XML payload.  Turning into SOAP might have some benefits, and would still allow you to use the spiffy SMTP transport, but I'm all about simple, too.  Second, I've been running email to blog for nearly a year, and I've never had a problem, for a couple reasons: I use a separate mailbox, and because Radio will download only those emails with a specific subject line, so it's doubly unlikely that a spammer would get into my blog.  You could set up a whitelist, because you want to really restrict who posts.  If you wanted to get really crazy with it, you could require signed messages.  Note that this is different from the problems that Sam Ruby had with email to comment: he's exposing an interface that's meant to be public, Radio isn't.  Anyway, with Radio, email to blog should be more secure than opening Radio to the Internet; a port scanner that finds 5335 open has a juicy target.  In James' solution, it's straight HTTP, so it's not likely that a port scanner will treat it like anything but a web server, but with SMTP, I think you'd be even safer.  James says "This is simple. I can send data via port 80, using simple web protocols, and not have to worry about spam or custom servers."  I won't dispute the simple part, but it does sound like he has in fact written a custom server.  No doubt it's less code when written in Smalltalk instead of Java, but I'd bet that it'd be no worse implemented as SMTP.  In fact, I contend that you could make it all work in bloxsom with a shell script.  Of course, the Radio implementation is pretty simplistic, but the more I think about it, the more I think this could make a really nice weblogging system.