Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Support of paged feeds

  1. #21
    Junior Member
    Join Date
    Dec 2013
    Posts
    5
    Quote Originally Posted by ibsi View Post
    I dont understand it. BeyondPod would be the first Android Podcast player with this feature. Put it in the Pro Version and you have many new customers. And - as software developer - I think it is not hard to code. Only look into the feed to find the tags. If found, than go back for each page and add it to the list *done*.
    True, but there maybe some problems and design decisions (limit the depth of the search, find and treat loops sensibly and such...) Still, it's something a CS student should be able to handle in a busy week... :/

  2. #22
    Senior Member
    Join Date
    Mar 2012
    Location
    Boston area
    Posts
    859
    Quote Originally Posted by gverilla View Post
    I tried the feedly approach, but their archive seems to not retrieve articles older than the ones in the feed. This defeats the purpose of the feed archive...
    The feature would make BeyondPod so much more usable for me!
    Feedly hasn't been doing this very long, so they can't've fetched older episodes. Google didn't have any episodes from before they started, either.

    Most feeds delete the mp3 file when they remove it from the feed, so synthesizing the URL pattern from existing episodes will generally fail. Many CDNs put a random string in the middle of the mp3 link just to defeat such searches.

  3. #23
    Junior Member
    Join Date
    Dec 2013
    Posts
    5
    Quote Originally Posted by Dennis Rockwell View Post
    Feedly hasn't been doing this very long, so they can't've fetched older episodes. Google didn't have any episodes from before they started, either.

    Most feeds delete the mp3 file when they remove it from the feed, so synthesizing the URL pattern from existing episodes will generally fail. Many CDNs put a random string in the middle of the mp3 link just to defeat such searches.
    Which is why feedly isn't an archive solution. Paged feeds are though, because they imply by design, that older feed entries are being preserved and therefore older episodes will be accessible even after dropping from the main feed.

  4. #24
    BeyondPod Team
    Join Date
    Feb 2012
    Posts
    1,033
    This is a bit of philosophical post - just my personal opinion on the subject.

    If the publisher intends to keep the media available for a long period of time it will be downloadable in both Feedly or Paged feed the same way. If the publisher removes the media, if using paged feeds, they (hopefully) will trim the entries for removed episodes from the feed, while Feedly will keep it (but now with a broken media link). In this sense Feedly is actually a better "archive" then the paged feed -at least some historical information of what is in the feed is preserved.

    The reason why we are somewhat hesitant to implement paging feeds in BeyondPod it is that we are starting to see a change in the way information is being distributed - a (somewhat sad) change from the standard RSS/Atom feed format to more (proprietary) JSON format. RSS Atom feeds are still the king but most of the information sources are slowly dumping RSS support for their own JSON format. While Google Reader was serving standard Atom feeds, Feedly is now serving proprietary JSON, Twitter also recently dumped their RSS support, You Tube while still has it, tries to hide it. I think that it is matter of time where Feed Burner (or iTunes, or some other publisher tool) will start serving JSON formatted feeds rather than RSS.

    RSS/Atom formats were conceived in the world of static web pages where browsers were still requesting html files - hence the current paging/archiving mechanism in RFC 5005 uses internal links to the other pages or the archive.

    In the new REST/JSON world, paging is done by supplying parameters to the REST calls. Among many other benefits this allows you to request any page or range of episodes without having to "walk" the chain of pages that leads to it.

    One of the reasons why BeyondPod supports Feedly is because it currently provides a natural "bridge" between the old RSS world and the new REST/JSON world. As far as paged feeds, if Feedly adds support to paged feeds to their parsers they can pull the historical entries in one pass, if they don't, they will start accumulating the old entries over time and in an year of two will have the a sufficient archive.

    Again - my personal opinion - if podcasting is to survive as a distribution medium in the future (...10+ years) we have to start looking away from the RSS feed standard and try to define a viable open JSON/REST standard that can include paging and media and chapter marks and donation links and anything that we tried to "jam" into the RSS over the years.

    Stefan

  5. #25
    Junior Member
    Join Date
    Dec 2013
    Posts
    5
    Thank you for taking time to explain your position on the matter!
    I see your reasoning, but I see some problems with the implications!

    The future you propose is heavily relying on CDNs (like feedly, so later, for convenience, they are referred to as feedly as a place holder...) to distribute the feeds instead of the podcast producers themselves. There is no standard for RESTful distribution of podcasts (please correct me, if I'm wrong!), so we (the listeners as well as the producers) have to depend on the use of feedly's, which will be supported by the major apps. Or we could use old-timy deprecated RSS and hope, that it will be still supported!

    I'm not comfortable with abandoning RSS, until there is a (standardized) format to replace it with. Sure feedly will provide any feed content down the line (AFAIK, actual feedly doesn't retrieve prior paged feeds...), but they are not prohibited to just arbitrarily drop features and/or limit or change their API like this at any point. While I don't foresee it happening in the near future, this is no solution fit for a +10 year scope!

    Back to the topic of paged feeds: This feature is already in the RSS standard, it just needs an implementation to use the advantages! It is not intrusive to the design of your app or particularly hard to code. For me however, the feature is a significant usability improvement!
    So, if there emerges a new standard for feeds, that gets the advantages of REST and RSS right and supports something similar to a, I'm happy to use to it. But, for reasons stated above, my hope is, that you don't place all your bets on the feedly's of the world...

  6. #26
    Junior Member
    Join Date
    Jun 2016
    Posts
    1

    Supporting the request for paged feeds

    I would also like to see the feature of paged feeds in Beyond Pod.
    I'm not only user of Beyond Pod, but also maintainer of jekyll-octopod and we support the generation of paged feeds there as well.

    Cheers,
    Stefan

  7. #27
    Junior Member
    Join Date
    Nov 2013
    Posts
    9
    More and more Podcasts are using paged feeds...
    Why isn't this standard feature still not implemented in BP?

    Even Podlove publisher (the most common podcast plugin for wordpress in Germany) is reommending paged feeds:
    https://podlove.org/paged-feeds/

    So please implement that... For about 30% of the podcats I hear I have to use another Podcatcher to hear older episodes.
    I still prefer BP because of the better UI, but that kind of sucks, and in the long run I'll abandon it...

  8. #28
    BeyondPod Team
    Join Date
    Mar 2017
    Location
    US
    Posts
    787
    The request will be put in for the BeyondPod team to discuss if this is something they would like to implement. Thank you.

  9. #29
    Junior Member
    Join Date
    Jun 2018
    Location
    Indore
    Posts
    1
    The framework supports paged feeds via Integration Broker message segments.


    Google Maps Scraper Software

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •