Marc Barrot comments on the new driver architecture for RSS aggregation:
This is a really cool feature. It opens up Radio's aggregator to new syndication formats, or to alternate formatting of existing formats, the first very clever answer to a current on-going issue with rss syndication, cf here , here , and here .
I think it answers a different (and more interesting) question: how can non-RSS formats flow into the news page? Phil Wolff, in the same DG thread:
Does this mean I can syndicate/aggregate XML DTDs completely unrelated to news/blogging (with appropriate code, of course)? For example, job listings, resumes, RFPs, etc., defined elsewhere?
Yes. And this is interesting, to the extent that XML formats of the multiple-item-per-file flavor exist, or can be easily produced -- say, from databases, using increasingly popular SQL-to-XML features.
It's worth noting that a UserTalk driver in Radio is not the only (and maybe not the easiest) way to assimilate such non-RSS formats into Radio. While not a huge fan of XSTL, transforming a non-RSS XML format into RSS .91, .92, or 1.0 (any of which Radio can already consume) is a really good use for XSLT. Note that Radio need not directly support XSLT in order to have the use of it. Web-service-based XSLT engines are available.
But to each his own. As the Perl folk say, There's More Than One Way To Do It.
In any case, this new feature deals with consumption of feeds by Radio. And it aims to broaden the universe of such feeds, which is a really good idea.
My questions were, instead, about tuning the production of feeds. One option, as Rahul suggested, is to offer to truncate long descriptions. I think that could look something like this.
In system.verbs.builtins.radio.weblog.writeRssFile, change from:
add ("<description>" + adritemcache^.text + "</description>");
desc = descriptionTrim (adritemcache^.text);
add ("<description>" + dec + "</description>");
where descriptionTrim reads a value from a Pref:
Truncate RSS Description? 0 means no, >0 means yes and specifies the length
As a general rule, I believe RSS is best used for notification, not bulk transfer. Readers of RSS feeds will benefit when writers can streamline such notifications, relying on the linking power of the web for follow-ups. Writers of RSS feeds, as we've said, can do this streamlining now, at the cost of some extra work -- writing a separate story, then blogging a link to it with a short leading blurb. In practice, I'm sure this will rarely happen. The truncation option, requiring no effort of the writer, should help writers notify readers, and readers assimilate lots of diverse notifications, with a minimum of friction.
Former URL: http://weblog.infoworld.com/udell/2002/03/16.html#a144