bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lars Ingebrigtsen
Subject: bug#45477: 27.1; RFE: Make full RSS fragments available for nnrss servers
Date: Mon, 28 Dec 2020 01:05:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Tim Landscheidt <tim@tim-landscheidt.de> writes:

> 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?

> 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

[Prev in Thread] Current Thread [Next in Thread]