Since I wrote the program that generates the RSS feeds for nntp.perl.org and since Robert nicely set it up and everything, I've had a few people ask why it doesn't also provide the full content of each article in <item> element's <body> section. There's many reasons, but the main one is: it's too damned much bandwidth to make an RSS file that gives you the last N messages on a list, or the last M-day's-worth of messages, for useful values of N or M. The values of N or M have to err on the side of being large, so that clients that don't poll frequently don't miss out on some posts; but that meas that clients that do poll frequently (say, every half hour) still get the whole potentially huge file all recent messages.
The basic problem is that the server doesn't know exactly what messages you have and haven't yet read, and so it can't give just just what's new to you. But it doesn't have to be that way: suppose the server keeps track of this, by having each RSS client access a unique URL like http://whatever/thing_rdf_gen.pl?xyz123 where xyz123 is some unique ID for that client. The program that dynamically generates that RSS feed would show items that it didn't already show last time, and then update its little database for user xyz123 so that it would know not to show them the next time.
Or one can have a framework where each client says to the server "here's the IDs of items I've seen; now what items do you have that aren't in this set of IDs?"
Or one can have the client say "Give me the IDs of everything you have, and then I can ask for full details of everything that's new to me".
The problem is that all of these options are solutions that have existed practically forever for NNTP, and reiterating them for RSS seems really quite wrong-headed to me, like pointlessly wrapping SMTP in XML-RPC. I have no grand conclusion here, but rather three incomplete thoughts:
* An "rss2nntp" proxy CGI should be simple to produce; it'd basically be just a newsreader that dumps the new news files in an RSS wrapper. The per-user data on the server is basically just a
* While we're at it, an "nntp2rss" program should be simple to produce: say, as a program that polls a given RSS feed, and every time it sees a new item, posts that item's data to a given newsgroup (whether it's one newsgroup per feed, or what, is an open issue).
* The fact that these things are possible, sane, and in fact trivial to implement, suggests that NNTP and RSS are not radically different things. Protocol-wise, they are clearly different -- and that's most of what I just said. And at the basic level of items versus posts, there are some basic problems with expressive range (you can express things in an RSS item that there's no
Generalization: maybe most situations that suggest/allow/require a trivial protocol2protocol proxy, are situations where what should really happen is for the clients of each protocol to get a bit smarter, so that the proxies aren't needed in anything but the short-term.