BTW, next year will be the 20th anniversary of RSS.#
I'm traveling later this week, so am trying to wrap up my work on the JavaScript implementation of XML-RPC in the next couple of days. There are issues that will linger, as there always are in projects like this. 💥#
If it doesn't have an RSS feed it isn't a podcast #
Please if you make a podcast, remember that. It's actually a lot more important than you probably realize.#
The reason it's important is this. As long as there are RSS feeds for every podcast, no tech company, like Google, Apple, Amazon, etc can own podcasting. It remains an open platform. It and HTML/HTTP are pretty much the last bastions of the open web.#
A reporter told me the other day that he was doing a podcast in the 1990s. Not possible, I said. RSS didn't exist until 1999, and we didn't define the podcasting features until 2001.#
I did implement a JSON version of XML-RPC as part of the package, and it works really nicely, but has at least one major undecided feature. I'm asking that people who think about JSON give this some thought, and perhaps suggest prior art to look at. #
First the types that work. These XML-RPC types are not a problem because JSON understands them. When it sees one of these in JSON text, the parser will create a property or object with the correct type. #
What happens in the current implementation? The value is converted to and transmitted as a string. You can test it by running the betty test app locally and calling examples.echoParams using the debugger. Here's a screen shot showing a setup for testing base64 data, and here's one that tests a dateTime.iso8601.#
As you can see from the screen shots above, dateTime.iso8601 and base64 types are converted to strings. The server toolkit will pass them up the stack as strings, where the XML-based version will pass up Date and Buffer types.#
I put this out there as a design problem for JSON experts to consider.#
Update: An egregious hack for adding date and base64 types to JSON.#
