[drupal-devel] [feature] More flexible rss output

Tue Feb 1 00:17:30 UTC 2005

 Project:      Drupal
 Version:      cvs
 Component:    node system
 Category:     feature requests
 Priority:     normal
 Assigned to:  walkah
 Reported by:  walkah
 Updated by:   drumm
 Status:       patch

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.

drumm

Previous comments:
------------------------------------------------------------------------

January 31, 2005 - 15:28 : walkah

Attachment: http://drupal.org/files/issues/format_rss_item.patch (4.06 KB)

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.

------------------------------------------------------------------------

January 31, 2005 - 16:39 : Dries

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.

------------------------------------------------------------------------

January 31, 2005 - 17:36 : geeknews

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

------------------------------------------------------------------------

January 31, 2005 - 18:02 : drumm

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).

-- 
View: http://drupal.org/node/16513
Edit: http://drupal.org/project/comments/add/16513