Atom Feed - Multiple Links

[escholtz]

It looks like gorilla atom feeds don't support multiple links even though the atom spec does:
https://tools.ietf.org/html/rfc4287#page-3

From their example:

<link rel="alternate" type="text/html" hreflang="en" href="http://example.org/"/>
<link rel="self" type="application/atom+xml" href="http://example.org/feed.atom"/>

I'd like to add support for this but I wanted to get feedback from the package owners first. As far as I can tell, RSS doesn't have a corresponding feature. Suggestions on your preferred approach?

[elithrar]

If you can do it in such a way that:

• It doesn't break RSS
• It doesn't break the public API

... then I'm OK with it.
On Sun, Feb 7, 2016 at 1:20 AM Eddie Scholtz notifications@github.com
wrote:

It looks like gorilla atom feeds don't support multiple links even though
the atom spec does:
https://tools.ietf.org/html/rfc4287#page-3

From their example:

I'd like to add support for this but I wanted to get feedback from the
package owners first. As far as I can tell, RSS doesn't have a
corresponding feature. Suggestions on your preferred approach?

—
Reply to this email directly or view it on GitHub
#32.

[escholtz]

I took a look and I don't immediately see an elegant way to do it without breaking the public API.

I decided to switch to the example from the golang blog (https://github.com/golang/tools/blob/master/blog/atom/atom.go) since it supports multiple links and validates without errors/warnings. I don't need to support both RSS and Atom so it's a better tool for my use case.

[d-smith]

Without support for multiple links in the atom feed, this package can't really be used for Atom feeds of significant size as previous and next links won't be available to navigate the feed. You could serve up a massive feed that contains everything, but it's not efficient for long running followers as they have to retrieve everything to get the latest entries, and not efficient for the server as the web caching can't be used.

[mastoj]

I totally agree here, a library like this should follow the specs of the format they're trying to implement. Don't get me wrong, great work with the lib, but I had to make a separate fork of it to add the missing things to the atom format. At the same time I understand that it might be difficult to change gorilla/feeds since it would break the public API most likely.

If interested in the changes we made they can be seen here: unacast@85cd1cf. Note that I don't care about the abstraction, I work directly with the AtomFeed.

[kisielk]

Now with versioning we could break the public API. If anyone is interested in working on this, PRs would be welcome. Ideally some discussion of the proposed design would be good so that we can arrive at a design everyone agrees upon without wasted effort.

[stale]

This issue has been automatically marked as stale because it hasn't seen a recent update. It'll be automatically closed in a few days.