💾 Archived View for rawtext.club › ~sloum › geminilist › 002576.gmi captured on 2020-10-31 at 14:38:12. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

For consideration: JSON Feed

easeout at tilde.team easeout at tilde.team

Mon Sep 7 03:30:17 BST 2020

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

On Sun, Sep 06, 2020 at 05:53:45PM -0700, mailinglists at ngalt.com wrote:

I've been seeing people talk about syndication formats how we'd like something a little less annoying than RSS and Atom.

I'd like to suggest JSON Feed as a possible alternative:

https://jsonfeed.org/

JSON Feed has a healthy amount of acceptance in the syndication space… enough acceptance to satisfy me, that is. And besides RSS, Atom, and JSON Feed, I don't know of any other common syndication formats at all! So I'm assuming there are no well-accepted syndication formats that are line-oriented. Given that, I don't think we need to invent a new syndication format. JSON feed is simple enough:

For a publisher, JSON feed should be easier to write than RSS or Atom, but not by a wide margin. If you're just filling out a text template, it may not make much of a difference to you. I maintain a tool that produces Atom feeds for Gemini blogs, and I would be happy to produce a JSON Feed as well.

For a consumer, the difference is probably bigger. I expect JSON Feed to be substantially easier to parse than RSS or Atom. Basic JSON parsing utilities are pervasive and usually just produce an object. The last time I did XML parsing, it was much more complex and involved responding to callbacks during an XML tree walk job.

So, I would like the consumers of feeds (CAPCOM and Spacewalk to name two) to give opinions about what feed format should be our de facto standard. I imagine it makes the most difference to them. But I'm inclined to think JSON Feed would be best. After all it might make me more likely to create a feed-consuming tool than if the standard was XML.

Obviously, we generally wouldn't use content_html. We could either use `content_text` or, if we're feeling particularly insular, `_gemini_text` (see the Extensions section of the spec)

Using content_text sounds fine to me, but I don't know the spec well enough to make a call.