Add some form of RSS support #791
Assignees
Labels
area:backend
Everything backend related
area:frontend
Everything frontend related
area:http-server
HTTP server of the backend
kind:new-feature
A new feature
needs:research
Needs research as we are lacking knowledge to make an informed decision
Comments
LukasKalbertodt
added
area:http-server
|
Some comments:
|
|
Should appear as a tab in the "Share" section. |
LukasKalbertodt
added a commit
that referenced
this issue
Nov 15, 2023
This adds RSS feeds for series in tobira as outlined in #791. It is still missing the caching that @LukasKalbertodt mentions in the issue, which is to be done in a follow up PR. ~~- [ ] This is also missing a mechanism for updating the feed when new events are added, which I realize makes these feeds kind of useless at the moment. At least that should still be added in this PR.~~ ~~- [ ] I don't know exactly yet how we can tell feed readers that the feed has new content, or if that is even necessary.~~ Edit 2: My limited knowledge about RSS led to the above assumptions, but after doing some testing as described below it turns out we don't need to implement anything like that. - [x] And I also still need to look into some specific tags like the `<itunes:...>` ones that are present in the feeds of the current ETH video portal. They aren't part of the current (but pretty much ancient) RSS specs but might be a worthwhile, if not mandatory addition (even if they are only necessary for the feeds to work with itunes). We need to test how the generated xml works in different RSS readers (they all appear to be doing their own thing), and probably adjust a couple of things based on these tests. - Edit: I tested different desktop/web ("Feedly", "Inoreader", "The Old Reader", "CommaFeed" and mobile (android "RSS Reader", "Feeder") feed readers. Some findings: - the desktop readers don't show thumbnails, which kinda sucks (mobile readers do tho). There is a workaround in adding an image to the `description`, but that would also clutter the entry itself. I also considered adding an embedded video to each item, but besides the cluttering argument, the items a) link to the videos, b) some readers already embed the videos automatically and c) all readers also feature a download option (not sure if that can be disabled, which might be an issue seeing as some institutions don't want their videos downloadable). - when adding a video to a subscribed series in tobira, the mobile feed readers update automatically. Desktop readers "Inoreader" and "The Old Reader" also pick up on the updated feed, but updating has to be done manually. "CommaFeed" has an option to "fetch all feeds" or sth, which also updates the feed. "Feedly" however ~~does not update the feeds, even when using their "refresh" button. So this might still need to be imlemented on our side (sigh...)~~ updates automatically, but less regularly, it appears (I have found no way of configuring this, might be behind a paywall). Actually, now I suspect that every reader updates automatically after a certain time period. Again - total RSS noob here.
|
Closing as initial support for this has landed in #959. Bugs, further improvements and the like can be filed as new issues. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@oas777 mentioned today that he wants RSS support in Tobira. At least in some form. He specifically mentioned the use case of: students pasting the RSS link into their reader-software and then (a) having a form of bookmark and (b) being able to download the video for offline consumption. I would further add the use case of users putting RSS links of series into their readers to be notified when a new video is published in that series. In particular, I know RSS mostly for this ability of being notified of new content. Copying the link of a single "thing" (e.g. video) seems weird to me. However, I do see the use case of offline consumption.
Here, I will just quickly describe what I know and how we could go about this.
To provide an RSS feed, we would provide an XML document in a specific syntax. For example, one could add the following routes:
/~rss/video/<id>and/~rss/series/<id>. Both would return an XML that was produced on the fly to represent data of that video/series. (Caching might be useful, especially due to the polling nature of XML.) The UI would then need to somehow provide the user with these links.Of course, we would need to test this, as I currently have no idea what RSS readers are capable of. Can they deal with dual stream video even? Likely not? Then RSS for those videos is completely useless? And also can we provide different video resolutions for the reader to chose from?
The text was updated successfully, but these errors were encountered: