bug#45477: 27.1; RFE: Make full RSS fragments available for nnrss servers

[Tim Landscheidt]

Lars Ingebrigtsen <larsi@gnus.org> wrote:

>> Some RSS feeds provide additional data in extra tags; for
>> example, http://feeds.feedburner.com/DougLovesMovies (and
>> others) includes information for/from iTunes:

> [...]

>> |       <itunes:title>Jimmy Pardo, Matt Belknap, Eliot Hochberg and
>> | Garon Cockrell guest</itunes:title>
>> |       <itunes:episodeType>full</itunes:episodeType>
>> |       <itunes:episode>1286</itunes:episode>
>> |       <itunes:summary>In a special holiday Doug Loves Movies-Never
>> | Not Funny cross-over event, Doug welcomes Jimmy Pardo, Matt Belknap,
>> | Eliot Hochberg and Garon Cockrell to the show.</itunes:summary>

> This information?

>> |       <content:encoded><![CDATA[<p>In a special holiday Doug Loves
>> | Movies-Never Not Funny cross-over event, Doug welcomes Jimmy Pardo,
>> | Matt Belknap, Eliot Hochberg and Garon Cockrell to the
>> | show.</p>]]></content:encoded>

> [...]

>> |       <enclosure
>> | 
>> url="http://feedproxy.google.com/~r/DougLovesMovies/~5/4ig02kQVqkQ/7d50103f-d685-4f0f-814e-b38fd2d643d8.mp3";
>> | length="46292323" type="audio/mpeg"/>

> I'm not very familiar with nnrss, but it looks like the itunes: info
> mostly replicates the info in the other fields?

No; for example and especially in my use case at hand, the
content of itunes:episode is not contained anywhere else.

>> It would be very useful to have this information available.
>> A very simplistic solution would be to add item to the tuple
>> that gets pushed to nnrss-group-data by nnrss-check-group so
>> that it can be accessed via:

>> | (nth 9 (alist-get
>> |         (gnus-summary-article-number)
>> |         nnrss-group-data))

>> (This method, with 9 replaced by 2 or 6, already allows ac-
>> cess to "pure" representations of title, URL & Co.)

>> However it might be prudent to have a more stable inter-
>> face :-).

> Sure, I guess stashing it there would make sense, but it would require
> people that want to use the info to write a bit of code, right?  Just
> stashing all the info there seems a bit... odd to me somehow.  I don't
> think any other backends do that?

> So I'm wondering whether this could be fixed in some other way, that
> would be useful to everybody without writing further code to use the
> data.  So would it make sense just to include the data from the extra
> fields here in the message body?

To draw a bigger picture: My use case (and existing workflow
with newsticker) is, when displaying an episode's Gnus arti-
cle, to provide the user (me) with a command to import the
episode's data (feed title, episode number, episode title,
episode URL) into my database for further processing.
Therefore, I need the data, and I need it in a format that
can be processed further, and there will be a need for a
custom user function to process the data because each use
case will be different.

So just unconditionally mangling and dumping the data into
the message body will help neither me nor the users who just
want to use nnrss "normally".

I thought about including the raw XML fragments as either a
Base64-encoded X-Gnus-nnrss-Entry-XML header or a
multipart/alternative MIME part.  However, regardless of the
solution, Gnus would need to provide a function that returns
the DOM for the current/an article, and with the current de-
sign, adding an element to nnrss-group-data is probably the
easiest path of the three.

(If there was a major overhaul of nnrss, it could be inter-
esting to forego the intermediate nnrss-group-data saved in
~/News/rss/* and either store the feeds as pure XML files,
re-parsed on demand and available for further processing, or
write out all the articles as mbox files after parsing the
feeds, with the entries' fragments as MIME parts.)