Slashdot Mirror
Podcast App Breaker Adds Support For JSON Feed, Believes the RSS Alternative Could Benefit Podcast Ecosystem (medium.com)
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.
...is this news?
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.
I really don't think the parsing speed of RSS's XML is going to be an issue here...
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.
"Faster for computers to parse"
really? Is there a big problem waiting for your iPod to parse your favorite newsfeed?
Did one of /.'s new editors write this, or something?
JSON wowee WEB 2.0 is here again!
WIZZEEWIG! WIZEEWIG!
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.
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!
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
Because the "creator" of the wannabe-rss-replacement-in-json was on here a bit back touting his all-new all-singing all-dancing world revolutionary thing, mostly getting sceptical replies back. So now he's gotten a friend to cook up a quick "support" for it so he's got "proof" it's really better and cooler and hotter at the same time for lookit, some app nobody ever heard of supports it, so it must be good and popular, right? Right?
You can see it in the fact it's a medium.com post too. Because that's where all the k-rad kewl 2.0 peepl hang out these days. It's all about manufacturing hype. So get hyped already, you insensitive clod.
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...
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.
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.
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.)
The JSON output that PHP produces is absolutely FULL of escaped characters. They do have a bunch of options to the json_encode() function, but it's very confusing, and by default, the output is very, very messy. I wish it weren't, and I wonder which one or ones of the options I should add. And I also wonder why it's so unnecessarily verbose by default. The JavaScript function that does the same thing doesn't add all those unnecessary \ escapes for every other character.
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.
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.
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.
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 element whose type attribute has a supported value and adds the feed's URI from the value of its href attribute.
No, that's one possible way of discovering an RSS feed, but it is not the only way. I manage some podcasts of academic lectures with both technically literate and woefully illiterate consumers. The initial page that I present them is the RSS feed as an XML file. 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. The ones who will never understand computers will see on that web page the title, description, and an HTML5 audio player for each lecture in the podcast. It's a simple solution that works for everyone, requires no duplication of effort, uses just one URL for both humans and machines, and doesn't even need javascript enabled.
*for bonus points: the landing page that leads to the podcasts is itself an OPML file linking to the RSS files, transformed via XSLT into a web page. Every part of the site can be read via a web browser (even with javascript disabled!) or a feed reader that understands RSS and OPML. The URL of every page is also its feed URL.
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?
Facebook is a newborn elephant?
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?
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
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?
... 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?!
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!