HN Explorer

Ask HN: If you were to design the RSS today, how would you do it?

18 points by deepakkarki ↗ HN
I'm looking at discussing the current limitations, when RSS works and when it doesn't. More importantly how would you design a better (more powerful) system today - while maintaining the decentralised ethos of RSS.

12 comments

[ 1.3 ms ] story [ 42.0 ms ] thread
pjotr99
Use JSON instead of XML. Well some guys already build it. https://jsonfeed.org
quickthrower2
What's wrong with XML?
twobyfour
Verbose, unwieldy, harder to read by humans (especially without syntax highlighting) in terms of picking out key data. More unwieldy to write in most languages as well (most now have libraries that will convert a dictionary structure to [or from] JSON in a single call, while XML often still needs to be assembled element by element).

I think it would be an exaggeration to say that there's anything "wrong" with XML, but there's a reason JSON has by far overtaken it outside of "enterprise" applications.

That said, in some ways XML is preferable for standards - particularly in that there's a standard way to publish a document type specification, and widely available tools for validating a document against such specifications. The somewhat experimental equivalents for JSON haven't really ever caught on.

quickthrower2
With good tooling unwieldy and harder to read shouldn't be an issue for a transmission format. If you need to read a raw transmission you could have a tool that presents it a JSON. I find JSON hard to read though, so it's a personal thing.

Verbose might be a real issue because it takes more bytes to send the same message. But then if you care about bytes, I think protobuf is worth considering instead of both JSON and XML.

rurban
Also slower and insecure. JSON is the defacto interop standard over the line.
twobyfour
How is JSON any more secure than XML?

And no, XML is just as much a standard (in fact, a better defined one as a formal standard), and is still very much the default in most enterprise applications. JSON being more common in startup land doesn't make XML not a standard.

kristoff_it
Decouple it a bit more from html, too many RSS feeds contain html description/title fields. It's annoying both when you're showing them in a html page and when you're showing them in a native application.
lj3
I'd build it somewhere in between what it is now and Usenet. One of the biggest benefits of RSS is how easy it is to publish content. Two of the biggest downsides is the lack of interactivity and the lack of discoverability. What if all of the rss readers spoke to each other? What if you could see which feeds people were reading? What if you could add a comment to a particular post and have a discussion with other people who are reading it? What if you could be notified of updates to certain conversations the same way you're notified of updates to your feeds? A killfile will solve the issue of not seeing unwanted content or people. Maybe go with a federated model instead of peer to peer, so that the servers could scrape the internet for RSS content. That way discoverability isn't just limited to what you and your friends are already reading. Maybe use Cap'n Proto as the app-to-app wire protocol instead of http for real-time updates.

> Decouple it a bit more from html

Is that really possible? I've considered it quite a lot in the past few years, but I can never get past the fact that it has become the universal markup language. Even markdown converts to HTML before displaying (so it can by styled with CSS).

kristoff_it
One could argue that allowing markup at all in RSS fields might be an anti-pattern.
lj3
Not successfully. By far the biggest advantage of RSS is its so easy to publish content to a feed. The more difficult we make that, the more we shoot ourselves in the foot.
1123581321
It would be nice to be able to declare endpoints for structured responses to items. I'd like to be able to thumbs up/down or rate articles in a client and have it go back to the publisher in addition to helping me customize what I read.