One issue with offering per entry comment feeds is that there are an array of bots and aggregators that will continue to poll such feeds literally forever.
I’ve decided to only offer per comment feeds for a period of 90 days after the last comment has been received on any given entry. After which point, the autodiscovery link and the common feed icon will be removed from the page for that entry, and any attempt to fetch the feed will return an HTTP 410 Gone status code.
With a properly configured client, subscription to comments for a particular entry should be a matter of two clicks, and unsubscribing should be automatic.
Sam: I’m torn on this one. On the one hand, I can certainly see the appeal... but I’ve got some old posts that get legit questions or whatever spaced many months apart.
Hm. I guess one alternative would be to take your approach and tweak it... after 60 days, auto-generate a feed item that says “this feed is about to expire”, with a link to a persistent version of the feed for those who need it. Then after 90 days, 410 Gone.
James: at the moment, the only feed in which I include feed thread extension is my primary index feed, and no entries in that feed are older than 90 days.
Roger: I still have my overall comment feed which contains comments independent of which entry they are associated with. My problem with permanent feeds is that bots and feed readers will pound on them forever. And at this point, I have literally thousands of such feeds. That’s the problem I want to solve.
If you add in-reply-to elements to all the entries in your comment feed with an id attribute showing which message they’re replying to, then you can just add a feed-level ‘replies’ link pointing to that single comment feed. Only one comment feed for aggregators to subscribe to, but they can still tell which replies go with which messages.
IMO per-entry comment feeds are best for on-demand viewing rather than subscribing.
JamesH, if you say you will support it, I will add in-reply-to
elements to my comments.atom feed, but I would prefer to hold off until JamesS issues a revised spec where the id
attribute has been replaced with ref
. If it helps, I will also add a feed level replies
to index.atom, but I’d like to leave the entry level links as they are in that feed.
Note: I don’t have any true concept of threading in my weblog implementation, every comment is a reply to the parent entry.
May I suggest an alternative?
It seems to me you could solve the problem without closing the feeds down by backing off on expiry times.
For example, you could take the number of days since the last comment, and set an Expiry header for that number of hours into the future x 6. With this scheme, something that hasn’t been commented on for two days would be polled twice a day per client, and something that hasn’t been commented on for 90 days would be polled once every three weeks per client.
Obviously it won’t stop broken clients that don’t respect the Expires header, but you must surely have ways of dealing with that kind of thing already, right?
Obviously it won’t stop broken clients that don’t respect the Expires header
It is not my impression that the expires header is widely supported by feed consumers.
Sam, don’t do anything special for me. That was more a generic suggestion of how comments could be implemented without having to resort to hundreds of per-entry comment feeds. I wasn’t necessarily expecting you to change. I suspect most aggregators that support comments will just be converting from their wfw:commentRss implementation in which case they’ll be wanting entry-level thread links exactly the way you have them now.
If/when I ever finish adding threading to Snarfer I may get back to you with a request for a feed-level replies link to test with, but either way is good for me, and for now what you’re doing is perfect.
James: I really did like the idea. Subscribe to two feeds, and you get everything, and futhermore, comments are automatically attached to their correct parent. I hope you do implement this some day.
Kevin: I believe that most of my (now defunct) feeds are being fetched by bots or on behalf of people who no longer use the tool in question. Most people who leave Bloglines, for example, don’t delete their subscriptions.
Geof: Yes, a new comment would reinstate the feed, as well as the autodiscovery link and feed icon on the associated page. All for a period of not less than 90 days. And, if I were to determine that such a comment were spam (not uncommon for comments on old entries), all this would be reverted immediately.
James, RFC 2616 also says “This condition is expected to be considered permanent.” I realize that’s not a SHOULD or a MUST, but since 410s are pretty exotic as far as HTTP goes (i.e. there are fewer establised practices), it makes sense to follow that guideline.
I see two options:
- If ressurection is not necessary, then 410 should do
- If it is necessary, conditional GETs, 304 response codes (and perhaps Expires headers or max-age directives with increasing intervals as time from the last comment increases) should provide nearly the same benefits. Aggregator implements have more incentives to support all of these than 410, since they provide significant bandwidth savings even for regular feeds.
When I mark a feed with a 410 Gone, this condition is expected to be considered permanent.
My purpose for doing this is to encourage people to subscribe to the entries that interest them. This means that I am not interested in inserting annoying instructions after 60 days or any other such measures.
What I do want is for recipients of this status code to consider the resource as intentionally unavailable and that it is the server owners expressed desire that remote links to that resource be removed forthwith.
Somebody posting something of merit to a dormant entry which reawakens discussion, enough so to merit resubscribing is clearly an edge case. One that in all the years I have run this weblog, I have not come across.
I think it seems reasonable, given that it’s a SHOULD and not a MUST, but I get your point, Mihai. Given all the possibilities, I think this is the least offensive.
[Sam, the only quibble I have with your comment feeds is that they don’t give good anchors to comment permalinks: for example, your last above is given as intertwingly.net/blog/2223.html#c1144795969, when you’ve got fancy mod_rewrite that does the /YYYY/MM/DD/Title-Cased-Entry-Title bit; alas, the comment feed’s permalinks don’t go where they should. While everyone else is nit-picking, why don’t I join them? ;)]
the only quibble I have with your comment feeds is that they don’t give good anchors to comment permalinks
See if you like these any better.
See if you like these any better.
I know I do!