bug#64202: [PATCH] Gnus: Add back end for Atom feeds (nnatom)

[Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Sorry, I missed this email (I didn't realize debbugs doesn't forward all
messages to the author of the "bug report").

>>>>> Eric Abrahamsen writes:

    > Huh! In all my years of using and working on Gnus I've never used
    > a "foreign" server, nor have I really understood what it means. At
    > some point it would be good to make sure this works via other
    > entrypoints as well, but so far so good.

AFAIK it should work for any entry point which allows you to define a
new server or select method (Atom feeds are represented as servers with
a single group, so there is no way to create a group without a
pre-existing corresponding server).
I'll be honest though, I only ever use this method and
'gnus-secondary-select-methods', so I'm not really sure which other
entry points there are.

    > Regarding your earlier question about having this backend handle
    > RSS too, I'm not aware of any significant difference between the
    > two beyond the format of the XML. Is that true?

Yes, even the XML format is very similar.

    > If so, it seems like it would make most sense to merge the
    > code. Have you looked at nnrss? It would be good to know if there
    > was anything in there worth stealing for nnatom -- if one of them
    > has a faster parser than the other, for instance, or better logic
    > for keeping updates efficient.

The issue with merging the two is that nnrss saves feed data differently
(both on disk and in memory), and also represents each feed as a group,
with a virtual "server" holding all groups.
I'm not sure if it's possible/a good idea to migrate feed data from
nnrss to a hypothetical merged backend, at least not automatically.

Stefan floated the idea of adding RSS support, deprecating nnrss and
creating an interactive migration command - so users who wish to migrate
will have to do so manually (which should also potentially allow asking
the user some questions if the migration includes some non-trivial
steps).

nnrss does do some cool stuff that nnatom doesn't, though (for example,
it tries very hard to find an RSS feed when you provide it with a link
to a website, while nnatom currently requires a direct link to a feed).

    > I just subscribed to a feed with nnrss, and noticed that after I
    > marked all the items in the feed as read, I couldn't re-enter the
    > group and see the old items. It gave me "Can't select group". So
    > that's not very encouraging.

Honestly, from my experience nnrss has many small issues (although I
never encountered this exact issue).  It is partly why I developed
nnatom (previously I used a hack documented on the Emacs wiki which
converted Atom feeds to RSS feeds on the fly).

    > If you do want to expand this to be a general "feed" backend, we
    > might want to do some boring things like rename it nnfeed.el,

This is the name I thought of too, and I guess if two people thought of
it independently it's probably fine.
 
    > and add support for ridiculous things like JSON feed[0] (why?!?). I
    > assume a derived backend could handle JSON feeds by setting the
    > appropriate values for the `nnatom-read-*-function' deffoos?

I actually attached a derivative "nnjsonfeed" backend I made as an
experiment to one of my previous messages (it doesn't work with the
current version of the patch, but it won't be hard to fix).

It wasn't 100% conforming to the standard (JSON feeds support some weird
features like pagination, which can actually be supported very well in
theory by nnatom, but I didn't feel like doing that), but it worked and
it was very easy to make.

    > One of the awkward things about nnrss is that it's never really
    > fit well into Gnus' one-server-many-groups paradigm, which you
    > allude to in the nnatom Info section. Do you have any further
    > ideas in that direction?

Well, nnatom theoretically supports this paradigm, but it doesn't do
this with Atom feeds, since it doesn't really make sense IMO.
However, there is a standardized way to include links to Atom feeds in
HTML documents, so it might be a good idea to support adding them as
servers which show any linked Atom feeds as groups.

I also have a (very experimental) derivative backend using the API of
some website, which exposes various categories of content, which I
expose as groups (this is what I use to test support for multiple groups
in a single server).

As a side note: I had hoped to publish an updated version of the patch
by now, but unfortunately I was a bit under the weather lately, so I
didn't feel like working on it.

    > Thanks, Eric

Thanks for your testing and feedback,
Daniel