* James M Snell <[EMAIL PROTECTED]> [2005-07-12 02:00]: > The second extension is a comments link type that allows an > entry to be associated with a separate feed containing > comments. […] > > <feed> > <entry> > <link rel="comments" href="http://example.com/commentsfeed.xml"; /> > </entry> > </feed>
What I don’t like about this idea is that if a thread-aware aggregator wants to keep up with *all* discussion on a weblog, it will have to poll any number of comments-for-entry-X feeds per single main newsfeed in the general case – in the case of a typical weblog encountered in practice, that would be several hundred. Clearly, this is untenable. So I would prefer to define an extension element that expresses “this entry is a comment, posted in reply to the entry with the atom:id value given herein,” and define a feed-level atom:link/@rel value that points to such an all-comments feed. A thread-aware aggregator can then stay updated on any comments posted anywhere throughout the site by polling a single extra feed. Non-thread-aware aggregators can still get some use out of such a comments feed. Thinking about it, entirely unaware aggregators would probably get less out of per-entry feeds than a single unified feed – they’d need to be subscribed to each entry separately, hugely cluttering the feedlist. If you disregard unaware aggregators, you could even serve only a single feed to aggregators which contains both the actual weblog posts and their comments. Thinking about it, there’s no reason you can’t offer both: with another feed-level atom:link/@rel value you could point thread-aware aggregators to “the same feed, but with comments included inline,” so these only need to poll a single feed to keep up with what’s happening. Of course, none of these propositions are preclude each other. Providers may also choose to generate per-entry comment feeds, but only for a limited amount of new posts, and might want to expire old per-entry comment feeds by returning 410. This would be a clear and easy fit in the case of the popular scenario where old entries get closed against comments to reduce the site’s linkspamming profile. Or aggregators may choose not to stay aware of new comments for entries posted long ago. So I’m not arguing that per-entry comments feeds should in any way be precluded by the spec, because there’s no reason to do that. But overall, I think defining an extension element as outlined above and providing a unified feed of comments for all entries makes the most sense. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
