Slashdot Mirror

← Back to Stories (view on slashdot.org)

Podcast App Breaker Adds Support For JSON Feed, Believes the RSS Alternative Could Benefit Podcast Ecosystem (medium.com)

Posted by msmash on from the interesting-moves dept.

Erik Michaels-Ober, the creator of popular podcast app Breaker: The decentralized structure of podcasts creates a chicken-and-egg problem for JSON Feed to gain adoption. There's no incentive for podcasters to publish in JSON Feed as long as podcast players don't support it. And there's no incentive for podcast players to support JSON Feed as long as podcasters don't publish in that format. Breaker is hoping to break that stalemate by adding support for JSON Feed in our latest release. As far as we know, Breaker is the first podcast player to do so. Unlike other features that differentiate Breaker, we encourage our competitors to follow our lead in this area. The sooner all podcast players support JSON Feed, the better positioned the entire podcast ecosystem will be for the decades to come. JSON is more compact than XML, making it faster for computers to transfer and parse, while making it easier for humans to read and write. Updating Breaker to support JSON Feed was fun and easy. It took us less than a day from when we started working on it to when the change was submitted to the App Store. Update: Julian Lepinski, creator of Cast (an app that offers the ability to record, edit, publish and host podcast files), announced on Tuesday: Like a lot of software, much of Cast's internal data is stored in JSON, and publishing JSON data directly would be pretty straightforward as a result. So I sunk my teeth in, and in about half a day I'd added experimental JSON Feed support to podcasts published with Cast.

36 of 57 comments (clear)

  1. One of many by sl3xd · · Score: 1

    At this point, Podcast App Breaker is following the herd; anybody who's been tracking it has seen most of the actively-developed feed readers support the new JSON feed format - and why not - it's something 'new' for the developers to do, so it's a bit more fun than the normal drudgery.

    The problem that remains, though, is that there aren't too many publishing apps that use it yet.

    --
    -- Sometimes you have to turn the lights off in order to see.
    1. Re:One of many by Archangel+Michael · · Score: 1

      JSON is not a new format, and the fact that it is for rejigging RSS feeds is proof that people don't understand how it is just another format.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  2. Faster? by mccalli · · Score: 1

    I really don't think the parsing speed of RSS's XML is going to be an issue here...

    1. Re:Faster? by slack_justyb · · Score: 1

      I really don't think the parsing speed of RSS's XML is going to be an issue here...

      The problem isn't reading it. It's building the DOM that goes behind anything XML. That DOM incurs a slight overhead. Building a DOM, giving it all the abilities to move forward, backwards, n-th node, etc is what *some* people have massive issues with. Now that sounds a lot like an issue with the thing that's in charge of building the DOM and you'd be correct. Lot's of XML libraries have tons of things that they automatically do that no one needs, but really some of that can be argued for JS engines as well...

      But I'm with you on this, this all sounds insanely "meh" and honestly sounds like the, "oooh! JSON is so H-O-T right now" trend is kicking off. Just like the XML version of that trend was a few years back. I'm pretty sure in a few more years we'll all move past JSON and we will all have this same discussion about JSON feeds converting over to ((insert next big thing)).

      I will add this. There is a frightfully vocal group of folks who tout JSONP as the solution to by-passing all of the headache that comes with cross site XML. To which I usually say, "well there was a reason for that, but, hey it's your site, your gun, your foot, have fun." While nothing bad has happened yet and folks are (big air quotes)keeping tabs(/big air quotes), I won't be surprised for XSS exploits to rise up at some point in the not-so-distant future. It may not ever happen, but just seeing some of the handwaving that a lot of JS developers do (type safety for lamb sakes!!) all in the name of making things smaller, easier, and faster; I just can't help but think that there's something bad brewing.

      But not giving these folks their fifteen minutes in the limelight, denies what I've come to see as the status quo for all things tech. New, shiny, and waiting to be exploited before it too moves into the obsolescence bin.

  3. Compression by Luthair · · Score: 1

    Isn't compression more effective for XML as it would reduce the redundancy and likely eliminate the file size advantage of JSON.

    I would also argue that in many ways XML is easier for humans to write than JSON unlike the supposition in the summary.

    1. Re:Compression by Luthair · · Score: 1

      Thats definitely true, and XML libraries are more prone to vulnerabilities due to XML features.

  4. Why? by ilsaloving · · Score: 1

    This is probably hopeless, but I'm still waiting for someone to explain what this new feed format does above and beyond the XML one. So far the entire argument is "Because it's JSON!!111eleventy!"

    The whole complaint about dealing with malformed XML isn't going to be fixed with this new format. If people are malforming their XML, then they're also going to be malforming their JSON too.

    1. Re:Why? by bill_mcgonigle · · Score: 1

      The whole complaint about dealing with malformed XML isn't going to be fixed with this new format. If people are malforming their XML, then they're also going to be malforming their JSON too.

      And smart programmers are already using a feed parsing library that's using an XML parsing library that has relaxed parsing logic, to handle malformed XML.

      Guess what - if your feed is so broken that the popular podcatchers can't handle it, nobody is going to listen to your show anyway; it's not like incentives don't exist for publishers to host valid XML feeds.

      Maybe by the end of the year we'll be reading about bored developers who claim email is unusable crap because it's not a JSON feed.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:Why? by Jack9 · · Score: 1

      > I'm still waiting for someone to explain what this new feed format does above and beyond the XML one

      It provides superior readability (debugging), simpler format (more compact in terms of raw bytes), less specification in a format leads to more specific implementation (which is what most people end up doing with XML anyway), and better 3rd party support (XML parsing behavior is dependent on many many choices, where JSON has far fewer). This is one of those, less common, cases where less specificity in a standard leads to cleaner implementation.

      > The whole complaint about dealing with malformed XML isn't going to be fixed with this new format

      That's particularly naive. Malformed XML isn't even meaningful, given almost every implementation deals with a different standard of correctness. Compare the amount of code in a Lua JSON decoder to any specific Lua XML reader.

      --

      Often wrong but never in doubt.
      I am Jack9.
      Everyone knows me.
    3. Re:Why? by slack_justyb · · Score: 1

      Maybe by the end of the year we'll be reading about bored developers who claim email is unusable crap because it's not a JSON feed.

      You take that back right this second, least someone actually read that and get an idea about better email!

    4. Re:Why? by slack_justyb · · Score: 1

      He should update that to now include USB-C

    5. Re:Why? by radish · · Score: 1

      Compare the amount of code in a Lua JSON decoder to any specific Lua XML reader

      And now every client needs both. Yay?

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    6. Re:Why? by ilsaloving · · Score: 1

      I have to disagree with most of that.

      The problem (for me) is that those are completely arbitrary judgement calls that don't actually result in more correct output or development.

      Sure, XML is verbose, sometimes ridiculously so. But I cannot believe that anyone would consider it less readable and debuggable than a sufficiently complex JSON structure that quickly digs into quote, comma, and bracket hell. JSON is more *concise*, yes. But clearer? I absolutely beg to differ. It's like arguing "Should I put the left curly brace at the end of the line or at the beginning of it's own line". It's a style issue. Not a functional issue.

      Simpler and has less specification? Yes, that is true. But look at the tradeoffs. It's a very similar argument as I have with MongoDB. With MongoDB, you can literally do whatever the hell you want, and it's fast, but you throw out all rigour and data integrity. ACID compliance? Fuck that. We don't need no steenking ACID compliance.

      With JSON, it's easy to just jump in and start using it. You can do whatever you want... but at a cost of throwing all structure and integrity out the window. If I give you a JSON blob, you have to trust that it corresponds to whatever schema you envisioned. There is no enforceability, unless you use one of many non-standard and incompatible third-party libraries to do your schema validation. XML has schema validation as part of the standard, and every XML validator needs to work with that standard, or be non-compliant. Ditto with data transformation like XSLT.

      IMO, JSON is to XML what NoSQL is to traditional SQL databases. A bunch of newbies looked at what exists, screamed, "This is too hard and pointlessly complicated!" and did their own thing, completely throwing out the window all the past lessons that caused those previous solutions to be created in the first place. In the process, they cause a whackton of disruption and headaches while they recommit all those past mistakes and reinvent the wheel all over again.

      The only benefit to JSON that I see, is that it lets people whip together a "data structure" without having to think the problem through first, consequences be damned. IMO just because it's easy to jump into a given technology, doesn't necessarily make it better in the long run. Especially when it empowers people to jump first and think later.

      Heck, I'm working with a client right now that, thanks to the developers deciding that JSON was the One True Way(tm), we are now having a a monumentally nightmarish time trying to analyze all that unstructured data because the thing is a big effing mess.

      Now get off my lawn! *waggles cane*

    7. Re:Why? by Jack9 · · Score: 1

      > The problem (for me) is that those are completely arbitrary judgement calls that don't actually result in more correct output or development.

      Is XML over-structured? Is JSON under-structured? Is there somewhere in the middle? I'm not sure these questions have value.
      People (including programmers) are lazy and looking through a standard to try to decide how to "properly" address a problem within a standard (XML). Is my implementation right? What if I missed something? That cursory overhead (of XML standard consumption) is acted (or not acted) on as a practical barrier. That's the reality.

      This results in super custom solutions, as you point out...

      > The only benefit to JSON that I see, is that it lets people whip together a "data structure" without having to think the problem through first

      You make an apt comparison to NoSQL. In fact, this would probably be true of any new format. Having arbitrary structuring is a quality that preceded XML. XML was a valuable tool, when in a vacuum of standard-less communication formats. Why is the pendulum swinging back? Access to information, comes to mind. For almost any API an unstructured API design results in a (unique) formal structure that can be referenced in a fraction of the time it takes to fully comprehend the XML standard. In this way, I think XML is over-specified. Now there's http://schemas.liquid-technolo... so you can just pick from any of the arbitrary XML variations. Are we any better off?

      > complex JSON structure that quickly digs into quote, comma, and bracket hell

      That is certainly a sad consequence of using JSON. \\\"some \\\'\\\\" string\\\\"\\\' etc. is nightmare.

      Having to work around the ignorant (and soon to be remedied) design decision to prohibit comments in the JSON spec, have led to a complexity/readability breakdown in many applications. I mean, it's only been decades for someone to make obvious improvements to JS...at least we have websockets? SMH.

      There is a lack of awareness regarding the (optional 3rd party) JSON Schema tooling.

      JS/JSON libraries don't deal with large payloads very well/at all. Being so simple a format, the parsers aren't robust. Most run their environment out of memory rather than treating it like a stream, as an option. There are entertaining discussion threads about how to efficiently use C to parse JSON, to the Nth degree.

      --

      Often wrong but never in doubt.
      I am Jack9.
      Everyone knows me.
  5. Re:Why is /. promoting this stupid thing so much? by DontBeAMoran · · Score: 1

    I doubt someone would be able to notice the parsing speed difference even on a 16MHz Arduino.

    --
    #DeleteFacebook
  6. Re:Why... by Archangel+Michael · · Score: 1

    Are you sure?

    This is nothing more than the latest "Mac vs PC" or "Windows vs Linux" argument. JSON vs RSS

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  7. Re:Why is /. promoting this stupid thing so much? by Archangel+Michael · · Score: 1

    What the Arduino is gonna need is more Memory*

    *Recent Experience in parsing a JSON into a stack of arrays in order to execute a simple loop to display on LED strands. While the Arduino could parse the JSON, and get it stacked into the arrays correctly, there was barely enough RAM to load the libraries needed to drive the LEDs. Eventually was able to get it to run, but gnarly ugly code.

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  8. chicken-and-egg problem by Errol+backfiring · · Score: 1

    The chicken-and-egg problem is easily solved in this case:

    "What chicken?"

    --
    Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
  9. JSON vs. XML benchmarks by zifn4b · · Score: 1

    JSON is more compact than XML, making it faster for computers to transfer and parse

    Technically correct, but seriously you're going to use that as a main part of your argument? ZOMG post the benchmarks. What's the difference measured in on today's computing power, microseconds? nanoseconds? Give me a break. I'll give you points for creativity and humor.

    --
    We'll make great pets
  10. Re:Why is /. promoting this stupid thing so much? by DontBeAMoran · · Score: 1

    AFAIK libraries aren't loaded into RAM, they're compiled to the flash memory for the code.

    --
    #DeleteFacebook
  11. Humans to read and write? by tlhIngan · · Score: 1

    JSON is more compact than XML, making it faster for computers to transfer and parse, while making it easier for humans to read and write

    I don't know about you, but I think there's something wrong if you're manually editing the XML or JSON files by hand everytime you post a new podcast. It might work for those once in a while podcasts that come around monthly or less, but I can't see someone actually not using a program to maintain the file, or having it automatically generated...

  12. Unicode safety by tepples · · Score: 1

    How does JSON waste three times the bandwidth compared to some bloated XML shite from 1999 or whatever? XML

    Let me hazard a guess as to what HornWumpus might have meant:

    XML can be encoded either in UTF-8 or in ASCII with numeric character references (such as я). JSON can be encoded either in UTF-8 or in ASCII with escape sequences (such as \u044F). But many JSON libraries, such as the one in PHP, use escape sequences by default to fit safely through a channel with any encoding that has ASCII as a subset. If your XML library defaults to UTF-8 but your JSON library defaults to escaping, and you are encoding a string in a non-ASCII script whose UTF-8 form uses two bytes per character, you'll see a threefold expansion between XML and escaped JSON. These scripts include Greek, Cyrillic, Hebrew, Arabic, and a few minor ones. Indic, Chinese, Japanese, and Korean use three-byte UTF-8, which expands by two in escaped JSON.

    Gzip hides some of this size difference, but not all because of the 32 KiB limit on backward references.

  13. Minification before compression by tepples · · Score: 1

    JSON's size advantage over XML comes largely from not having to repeat an element's tag name at the end of each non-empty element. Compression eliminates some of this advantage but not all. For one thing, more efficient encoding before compression allows more source data to fit into Gzip's 32K window. For another, the compressor doesn't have to spend bits on a backward reference for each end tag, and the backward references it does emit can be shorter because they refer to more recent data. It's the same reason that people minify JavaScript programs by removing spaces and comments and shortening variable names before sending them over the wire to the browser: it helps the compressor see more program at once.

  14. JSLT by tepples · · Score: 1

    XML can transform with XSLT clientside

    So can JSON, through JSLT. To get started with JSLT, see Vanilla JS and DOM Intro.

    (Hint: JSLT is just JavaScript that builds a DOM.)

  15. Re:Because propaganda by Anubis+IV · · Score: 4, Interesting

    Hey, I'm the one who submitted the story a few days back. I am neither the creator of the format, nor do I have no relation to the guys who created JSON Feed, nor do I have any relation to whoever submitted this summary today. Check my comment history. I'm just a guy who's been around Slashdot for way too long and thought it was weird that this format I was seeing reported everywhere else for an entire week hadn't yet been reported on Slashdot. While I had heard of the two guys behind JSON Feed prior to its announcement, I don't know either of them personally or professionally; I don't follow either of them via blogs, podcasts, Twitter, or anything else; and I don't have any vested interests in the format, other than liking that we finally have some movement in that space. Believe me or not. It's no skin off my nose.

    As for the replies to the story, frankly, most of the replies were clearly from people, such as yourself, who hadn't bothered following the links I provided, since they latched onto the incorrect notion that it's just a reimplementation of RSS in JSON. I'll grant that I should've done a better job of making it clear that wasn't the case in my summary (also worth noting: I simply wouldn't have submitted the (non-)story if all it was was RSS in JSON), and I think it's unfortunate that the name of the format is "JSON Feed", since that seems to be driving much of the confusion, but there IS more to it than just "wannabe-rss-replacement-in-json", which you'd know if you had actually read any of the stuff I linked.

    Not that I expected you or anyone else to do so, of course. After all, this is still Slashdot, and no one here reads the articles. ;)

  16. Re:Because propaganda by Anubis+IV · · Score: 1

    Oops, typo. Instead of...

    nor do I have no relation to the guys who created JSON Feed

    ...it should instead be...

    nor do I have a relation to the guys who created JSON Feed

    Obviously, the distinction is important.

  17. The problems isn't XML vs. JSON. It's data silos. by Hydrian · · Score: 5, Insightful

    XML didn't kill RSS Feeds. Switching to JSON isn't going to help it either. What is killing RSS Feeds? It is the big social media data silos. Facebook, Google+, maybe Twitter.

    Facebook is the 200lbs elephant in the room so I'll point to them. Instead of letting end-users select what RSS feeds / 'subscriptions' they wanted to add to their timeline, Facebook made their own non-standardize API that that content authors need to work with in order to let the end-users access the content the way they want. Google+ did the same thing. This takes time and energy from the content creators which is a limited resource. Instead of building an RSS aggregator in to their social media site, those companies decided to create custom APIs that can only be used with 'their' social media site. All of these moves are to get you consuming on their site and not how you'd want consume it.

    --
    No good deed goes unpunished.
  18. <link rel="alternate"> by tepples · · Score: 1

    I concede that JSON has no exact counterpart to <?xml-stylesheet ?> processing instruction. Instead, it needs an HTML file to kick off the transformation. However:

    This means that your human readers go to a different url than machine readers

    In the special case of a feed, both the human and machine readers go to the HTML version, be it HTML5 or XHTML. The machine reader finds the <link rel="alternate"> element whose type attribute has a supported value and adds the feed's URI from the value of its href attribute. The browser used by a human reader instead looks for a <script> element whose src attribute specifies the URI of a transformation script. The script then behaves as a limited-function machine reader, fetching and transforming the feed.

    The advantage of JSON Feed over RSS and Atom in this case is that the machine reader needs to parse HTML5 or XML only once, to retrieve the feed's URI.

  19. Accept: negotiation by tepples · · Score: 1

    This means that your human readers go to a different url than machine readers

    Not necessarily. Human readers will send HTTP requests whose Accept: header lists text/html before application/json, machine readers vice-versa. Then the server can use media type negotiation to serve HTML to humans or a feed to machines. A server behind a public cache, such as a server using a CDN or cleartext HTTP, does need to send Vary: Accept in the response so that the cache gets both the human and machine versions.

  20. Applying the XSLT or not by tepples · · Score: 1

    There is no link tag: the file they see IS the feed, presented as very nice HTML via XSLT*. If they are savvy enough to want to load it in a feed reader, then they just copy that URL into their feed reader.

    When a web browser parses the RSS feed, it applies the XSLT referenced in the <?xml-stylesheet ?> processing instruction to transform it into XHTML. How does a feed reader know not to apply the XSLT when it parses the same feed? Or does it apply each <?xml-stylesheet ?> processing instruction in turn and accept the first one yielding a root element in an XML namespace that it understands?

    Is it possible to produce more than RSS and XHTML from one feed?

    and doesn't even need javascript enabled.

    But it does need XSLT enabled. Wouldn't some of the same things that lead people to turn off JavaScript also lead them to turn off XSLT?

  21. Re:The problems isn't XML vs. JSON. It's data silo by Anonymous Coward · · Score: 1

    Bingo - honestly, JSON vs XML vs ASN1 binary files isn't what's killing RSS feeds. (Heck, we're supposed to be using ATOM instead of RSS anyway!).

    It's the fact that something like Facebook and Twitter is how people get their feed these days, and none of it interacts with RSS. Even blogs have given way to Twitter follows, to YouTube channels, to Facebook groups.

    Get your heads out of your backside and look around.

    Anyway..
    "JSON is more compact than XML, making it faster for computers to transfer and parse,."
    What sort of an ignorant, stupid statement is that? GZIP'd XML is more compact than uncompressed XML, so which do you think is faster to parse? Yeah, the uncompressed (LARGER) XML. Except that the difference in execution time is 'in the margin of error' these days. And with the sizes? honestly, they're both dwarfed by the MP3/MP4 media content anyway.

    "while making it easier for humans to read and write."
    This Is A BAD THING. it means that the parsers, instead of working with what is strictly correct, have to work with what looks correct to fallible human eyes. Nobody seems to care that humans can't read-or-write the media content, so why about the medadata format?

  22. Re:Is it really "easy to read"? by K.+S.+Kyosuke · · Score: 1

    It's easy to read for anyone avoiding harebrained language ecosystems such as PHP's.

    --
    Ezekiel 23:20
  23. Re:The problems isn't XML vs. JSON. It's data silo by K.+S.+Kyosuke · · Score: 1

    What sort of an ignorant, stupid statement is that? GZIP'd XML is more compact than uncompressed XML, so which do you think is faster to parse?

    I once (early 2000s?) benchmarked the fastest XML parser I could get my hands on against an S-expression parser. The S-expression parser was several times faster. Even worse, I was just firing NOP events in the SAX parser. That made a lasting impression on me as to what a clusterfuck of a standard XML has to be.

    --
    Ezekiel 23:20
  24. Not like alot of software by brantondaveperson · · Score: 1

    Like a lot of software, much of Cast's internal data is stored in JSON,

    Yeah, not really eh. XML, JSON, etc etc are all serialisation formats, and 'internal' data isn't normally how we refer to the data stored on disk. Podcast feeds are XML, stop trying to break them. Do you want to serve HTML up as JSON too?

  25. Re:The problems isn't XML vs. JSON. It's data silo by zippthorne · · Score: 1

    ... GZIP'd XML is more compact than uncompressed XML, so which do you think is faster to parse? Yeah, the uncompressed (LARGER) XML.

    That's not strictly accurate, whatever the base format is. Whether the uncompressed version is faster to parse depends greatly on memory speed. It can take longer to pull in the uncompressed version and parse it than the compressed version due the time wasted fetching from higher-level, slower memory.

    It's not intuitive that decompression + parsing should be faster than parsing alone, but it is far from improbable.

    --
    Can you be Even More Awesome?!
  26. Are people editting rss by hand? by 91degrees · · Score: 1

    I'm pretty zealous when it comes to the benefits of json over RSS, but the main point is that json is clearer, more compact, and simpler. Benefits that don't really apply here.

    RSS is entirely computer generated and computer decoded. It is an established schema. It is widely supported, and every platform that could possibly play a podcast has XML libraries.

    The size hardly makes a difference - I checked one of the feeds I like; it was 83Kb, and full of podcasts that were in the 8-25MB range. And most of the data was the text descriptions!