On Tuesday, July 12, 2005, at 12:42 PM, A. Pagaltzis wrote:
* 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.
If you're already creating an extension link type, why not throw in an
additional attribute too to help with that:
<feed xmlns:comments="http://example.org/commentfeed";>
<entry>
<link rel="comments" comments:updated="2005-07-12T12:53:15Z"
href="http://example.com/commentsfeed.xml"; />
</entry>
</feed>
Then you'd only need to poll the main feed unless it indicated an
update in the comment feed. Of course, if comments were threaded, you
have to cascade comments:updated values up through all the feeds in a
thread, and aggregators would have to follow updates back the other
way, potentially down multiple branches, to find all the updated leaves.
...which raises the question of whether an application like this might
beg a minimal feed for comments that simply pointed to an Entry
Document for each comment. Entries in such a feed would really only
require an atom:id, atom:updated, atom:link pointing to the entry
document, and atom:link pointing to the parent comment or entry.
atom:title could conceivably be considered undesirable bloat for such a
feed. Is Atom the right format for this need? An alternative might be
to define a format for this need that used Atom elements but had
minimalized cardinality requirements.
Well, enough stream of thought blabbering for now.
