More flexible rss output [#16513]

this patch does a few things:

* alters format_rss_item (in common.inc) to allow the $args paramater to be an array of arrays (optionally), so that extra arguments can have attributes - i.e. think enclosures
* introduces a nodeapi option for 'rss item', so that other modules can add additional info to each rss item
* patches taxonomy.module to add category information to feeds
* patches upload module to add enclosure for feeds (NOTE: rss only allows 1 enclosure per item). this would allow things like, say, podcasts to be available in drupal.

Comment	File	Size	Author
#9	drupal_452_rss20.tar_0.gz	35.63 KB	antipasto
#5	format_rss_item2.patch	4.61 KB	walkah
#5
	format_rss_item.patch	4.06 KB	walkah

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Dries CreditAttribution: Dries commented 31 January 2005 at 22:39

Some quick comments:

RSS allows you to specify multiple categories. Why only emit one?
Isn't the author-field supposed to hold the author's e-mail address, rather than the author's name?
Does it make sense to limit enclosures to files that have the 'List'-flag set?
As a user, I'd like to know (and have control over) what file will be used for the enclosure. How does other software deal with the fact that you can have multiple files but only one enclosure? Any screenshots or GUI suggestions? At a minimum, the implicit behavior should be clearly documented so the user can upload his files in the correct order (or something).
What is the rationale behind returning an associative array of arrays? Why not return an array of ready-to-use string? (eg. return array('<category>my category<category>');) Just thinking up loud.

I'd like to hear Neil's ideas on this.

Comment #2

geeknews CreditAttribution: geeknews commented 31 January 2005 at 23:36

One thing to remember is the spec does not limit enclosures to one item this has been discussed in detail by Dave Winer but it dows make sense to only allow 1 enclosure per post. In addition what the folks at Movable type did was put in a variable

If you look at

http://www.geeknewscentral.com/podcast.xml (MP3)
http://www.geeknewscentral.com/wma.xml (wma)
http://www.geeknewscentral.com/ogg.xml (xml)

These are multiple RSS 2.0 files with the same exact information included which allows podcasters the ability to publish multiple formats and to create seperate rss feeds with the extension of file.

You shoud review what has been done at this site with the plugin they developed It is worth a read and his implementation solved a great number of issues that MT users were having. http://brandon.fuller.name/archives/hacks/mtenclosures/

Being I am not a programmer and I do not fully know what this module does then it should be smart enough so that when a post is created with a hyperlink like http://www.geeknewscentral.com/podcast/anybsfile.mp3 that it reads that html automatically and creates the enclosure information the RSS 2.0 specification is very specific what needs to be included in that enclosure tag

With Podcatcher clients needing the URL, Length & Type

If this module ties into the aggregator then it is important that the aggreator parse this information completly so that those of us trying to put sites together like we are at http://www.techpodcasts.com/dp/?q=aggregator will be able to provide custom XML feeds

Comment #3

drumm

he/him

NY, US

CreditAttribution: drumm commented 1 February 2005 at 00:02

Array structures are useful because concatenating a bunch of arbitrary xml strings together does not necessarily produce xml conforming to whichever specifcation you are using. For example, there seems to be a limit of one enclosure per item. If everything is a string then there is no good way to determine that two of those strings are enclosures and one needs to go. Data structures make the information much easier to deal with outside of the module. Even if there isn't any fancy processing now it is a good idea to build it now.

Some documentation for how the array structure is constructed is definately needed. Here are some things I see by reading code:
- What if we want an attribute named 'value'? Replacing that with something that starts with a '.' is probably a good idea because '.' is a valid first letter of an array key but not a valid first letter of an attribute name, IIRC.
- What if we want to nest tags?
- What if we want multiple tags with the same name? Currently they are array keys and do not allow duplicates while they may be perfectly valid in the XML document type being targetted.

Notice that I never said 'rss' in the last paragraph/list. This is because I think that this XML generation is general enough to break out into another function and let other modules use for other XML-related purposes. You can see how I attempted to create this function at http://drupal.org/node/6992 (a duplicate of this issue which I will not have time to update before the 4.6 code freeze).

Comment #4

drumm

he/him

NY, US

CreditAttribution: drumm commented 1 February 2005 at 00:17

Oh and a big +1 for getting this functionality in before 4.6. I would really like to unfork this code in CivicSpace (leaves only the aggregator). I think what we have so far is enough to do it.

Comment #5

walkah CreditAttribution: walkah commented 1 February 2005 at 01:27

File	Size
format_rss_item2.patch	4.61 KB

OK - here's a patch with a bit better approach. I've reworked the $args paramater handling in format_rss_item to potentially take arrays with 'key', 'value' and 'attributes' keys (where 'attributes' are key/value pairs for the attributes).

Dries :
* multiple categories are now supported
* i've removed author - that actually slipped in by mistake - do we really want to expose $user->mail ? (i'd think not)
* i've added some help text to upload module noting that only the first "listed" attachment will be included in the rss feed. I think this makes more sense than trying to introduce additional UI. I don't necessarily agree that 1 enclosure per item makes sense but feedvalidator.org rejects it. Re-using the "listed" feature makes sense to me - but perhaps I'm mistaken. I would say that "unlisting" attachments is more likely used for, say, images inside a post, etc.
* i agree with drumm's reasoning for "why not to just give back strings".

drumm : this should address all of your concerns except for the nested tags - which doesn't occur in rss 0.92 (which we're supporting).