One major stumbling block we've come across in moving DownhillBattle.org from WordPress to Drupal is that WordPress supports RDF, RSS.92, RSS2, and ATOM feeds. We have lots of people using each of the different types of feeds, and we don't want to disrupt them. Drupal core only supports RSS.92, with a contributed module for ATOM support.

Support for RSS2 and RDF feeds would make it much easier for many people to switch to Drupal.

CommentFileSizeAuthor
#8 feeds.tar_0.gz1.95 KBJerk Face
#2 feeds.tar.gz1.91 KBJerk Face

Comments

Jerk Face’s picture

Jerk Face commented
Title: Support for Providing RSS2 and RDF feeds » Where should RSS2 and RDF feeds be linked?

The RSS.92 feed is located at node/feed. The custom module for ATOM feeds is locates them at atom/feed.

If we follow the convention set by the atom feed module, the new feeds should go in rss2/feed and rdf/feed. The other logical option seems to be linking the new feeds at node/feed/rss2 and node/feed/rdf.

Any preferences either way?

Jerk Face’s picture

Jerk Face commented
StatusFileSize
new feeds.tar.gz1.91 KB

Here are really basic RSS2 and RDF modules that link from /rss2 and /rdf

erikhopp’s picture

erikhopp commented

is this patch applied?

fyi: if you add a patch to an open issue, you should mark it status:patch, then when it is approved, the approver sets it to status:fixed.

sorry if it actually is applied, but i don't see any indication that it is on the devel list...

i hope the downhillbattle.org stuff is going well!

erik

Anonymous’s picture

(not verified) commented

Are these module suitable for CVS version?

Anonymous’s picture

(not verified) commented
Anonymous’s picture

(not verified) commented

I found these module can't pass the Feed Validator, problems are on the time tag, have futher pattch more?
thansk.

I really think it should be include in 4..5 core.

Jerk Face’s picture

Jerk Face commented

Changing status to active

Jerk Face’s picture

Jerk Face commented
StatusFileSize
new feeds.tar_0.gz1.95 KB

The feeds now pass the Feed Validator.

drumm’s picture

drumm
he/him
Location NY, US
commented

I have to say -1.

Sorry I haven't been able to be more involved in this issue, but I can tell you what I don't like about the current implmentation:

-makes 2 places to maintain code (node views and feeds) into four
-makes 2 levels of feeds, core node functionality and addon modules
-the feeds still aren't extensible (although that could be another issue)
-this only adds feeds for the front page when there are many more feeds
-its not for drupal cvs

Having said that, this code would be perfect in the contributinos CVS repository in sandbox/yourusername/... It should be published, but I think we can do better before Drupal 4.6 (most realistic place to target this functionality for Drupal core), so it doesn't need to be a full module.

I will have a chance to describe my ideas in some detail on the drupal-devel mailing list at some point, maybe sooner if I get poked enough.

Steven’s picture

Steven commented

How does this patch fit in with the aggregator/feed changes for extensible feeds,

killes@www.drop.org’s picture

killes@www.drop.org commented

Not a patch against current cvs.

Jerk Face’s picture

Jerk Face commented
Assigned: Jerk Face » Unassigned
Status: Active » Closed (won't fix)

It seems that people have standardized on RSS 2.0 as a base, so there's no need for this

hellata’s picture

hellata commented

Please don't give up -- there *is* a need for this.

There is no standard, AFAIK, using one format over the other. RSS readers handle RSS, RDF and Atom with equal ease.

And even if there was a standard for blogs, Drupal is not a blog; it's much more powerful, so why not use the power of callbacks to provide an extensible syndication framework ? After all, the internet evolves, and who knows what the next year's favorite format will be.

Right now, to develop an rdf/atom/whatever module, you have two options:

- override existing menu items, which is ugly and just plain wrong because it relies on assumptions about the order in which modules are processed

- implement a parallel hierarchy of menus and then either hack every module that relies on node/feed structure or (again) hack a theme to replace all node/feed links with node/rdf or something. Even uglier... And as was mentioned above, it will lead to duplication (quadruplication?) of things to maintain.

A belated disclaimer: maybe there is a better way to have multiple formats through modules that I haven't yet figured out.

Making core more flexible seems to be simpler than finding all the workarounds. For example, by default, the node module could still choose the current behavior. But if, say, hook_feed has been implemented, node should allow feed overrides. hook_feed's arguments could be similar to hook_block -- hook_feed($op = 'list', $delta = 0, $edit = array()). Default behavior would be to list the formats offered by the module. If $op is 'view', $delta would contain the format name ('rdf', 'rss 2.0', 'atom'') and $edit would contain the feed elements.

This way, you would always have the same feed URL structure and by allowing listing of the available feed formats, the user preferences could be set on site- or user- levels.