Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

171–180 of 225 posts

Re: JSON Feed

#171

Post by dwaite »

d0mine wrote: post #151
jameshart wrote: post #128

Earlier quoted context omitted.

Actually actually... the JSON spec doesn't define the concept of a JSON document. Neither http://www.json.org/ nor http://www.ecma-international.org/publications/files/ECMA-ST... actually specifies that a JSON 'document' is synonymous with a JSON 'value'. Now it's also true that JSON doesn't specify an entity that can be either an object or an array but not be a string or a bool or a number or null. So it's kind of t…

Why are you referencing the obsolete rfc? There is no restriction to object/array for the JSON text in the current rfc https://tools.ietf.org/html/rfc7159

The current RFC recommends the use of an object or array for interoperability with the previous specification. JSON being a bit of a clusterf* of variants, they tried to make the RFC broad then place interoperability limitations on it. (lenient in what you accept, etc etc)

Re: JSON Feed

#172

Post by ttepasse »

derefr wrote: post #134
russellbeattie wrote: post #98

For anyone who's tried to write a real-world RSS feed reader, this format does little to solve the big problems the newsfeeds have: * Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely. * Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do…

> Need to continually poll servers for updates? Miss. The point of these syndication formats (RSS, Atom, now this) was always to act as the "I'm a static site and webhooks don't exist, so poll me" equivalent of webhooks. These "pretending to be webooks" were supposed to hook into a whole ecosystem of syndication middleware that turned the feeds into things like emails. And that —the output-products of the middleware—…

HTTP 301 Moved Permanently is the out of band control channel. Sometimes it even seems to work, depending on software of course.

There was also a typical Dave-Wineresque invention of replacing the old feed with some special, non-namespaced XML with the redirect: http://www.rssboard.org/redirect-rss-feed

But of course the real problem is social. As in people simply stop blogging or stop caring. And of course tool developers don't care if someone doesn't want to use their software anymore and don't think of developing the right buttons for this edgecase.

Re: JSON Feed

#173

Post by Marazan »

mstade wrote: post #68
mstade wrote: post #66

Earlier quoted context omitted.

Right, but you inevitably end up with boilerplate "massage" code around your data anyway. Case in point: dates, any number that isn't just a number e.g. currencies or big numbers, URLs, file paths, hex, hashes. Basically any type that carries any kind of semantics beyond array, object, string, number, or null will require this boilerplate, only that your data format has no way of describing them except for out-of-ban…

Also, for what it's worth, your point is exactly why I mentioned E4X. Sure wasn't a panacea, but it had some things going for it.

E4X was exceedingly great. Loved it.

Re: JSON Feed

#174

Post by derefr »

ttepasse wrote: post #172
derefr wrote: post #134

Earlier quoted context omitted.

> Need to continually poll servers for updates? Miss. The point of these syndication formats (RSS, Atom, now this) was always to act as the "I'm a static site and webhooks don't exist, so poll me" equivalent of webhooks. These "pretending to be webooks" were supposed to hook into a whole ecosystem of syndication middleware that turned the feeds into things like emails. And that —the output-products of the middleware—…

HTTP 301 Moved Permanently is the out of band control channel. Sometimes it even seems to work, depending on software of course. There was also a typical Dave-Wineresque invention of replacing the old feed with some special, non-namespaced XML with the redirect: http://www.rssboard.org/redirect-rss-feed But of course the real problem is social. As in people simply stop blogging or stop caring. And of course tool deve…

> HTTP 301 Moved Permanently is the out of band control channel.

True, but requires you to be able to set response codes on the server. I can't make my Github Pages site, or my Tumblr blog, or my S3 bucket, emit a 301. And those are the sorts of things that RSS was designed for: static sites that can't just, say, tell their backend to email people on update. You'd think that, knowing that, RSS et al would have been designed with in-band, rather than out-of-band, control.

Re: JSON Feed

#175

Post by pfranz »

moolcool wrote: post #161
pfranz wrote: post #144

Earlier quoted context omitted.

Most of my experience is from Python. Each time I use it I have to look at the docs for etree (a library that ships with Python). We would hit performance and feature support issues with etree and tried lxml but had binary compatibility issues between our environments. The Hitchhiker's Guide to Python[1] (a popular reference for Python) recommends untangle[2] and xmltodict[3], neither of which I've used. I feel like…

Beautiful Soup is alright in most cases. JSON is handled much better than any XML library I've seen so far though.

Oh yes, I've used Beautiful Soup, too. If I remember correctly I had great luck with html, but issues with xml. It also is only a reader, not a writer.

Re: JSON Feed

#176

Post by Animats »

hayleox wrote: post #88
mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq ( https://stedolan.github.io/jq/ ) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.

I have an RSS client written in Rust that builds as a command line program.[1] I wrote this in 2015, and it needs to be modernized and made a library crate, but it will build and run with the current Rust environment. It's not that hard to parse XML in Rust. Most of the code volume is error handling.

[1] https://github.com/John-Nagle/rust-rssclient

Re: JSON Feed

#177

Post by stephenr »

robgibbons wrote: post #167
mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

JSON, given the same schema, will always be more efficient byte-for-byte than XML. In addition, JSON as a format is native to JavaScript, which itself is ubiquitous. That's not even mentioning raw readability/writability. Basically, XML is to JSON as SOAP is to REST. It had it's day, though it's obviously still useful, but we have better tools now. Frankly, I'm surprised we haven't seen a proposal like this sooner.

> XML is to JSON as SOAP is to REST

That's true. Both XML and SOAP are well defined, and well structured.

JSON and REST are both marginally defined, and thus we see constant incompatible/incomplete implementations, or weird hacks to overcome the shortcomings.

> we have better tools now

I think "the cool kids are cargo-culting something newer now" is probably more accurate.

Re: JSON Feed

#178

Post by stephenr »

zokier wrote: post #118
mstade wrote: post #28

Earlier quoted context omitted.

If there was an `XML.parse` just like there's `JSON.parse`, I doubt you'd say the same. As it stands, the added complexity in JS-land is to import a library that provides this functionality for you. Fortunately there are many, but I agree a built-in would be nice. It's a bit of a shame that E4X never landed in JS.

XML is fundamentally much more complex than JSON so any XML parsing library will inevitably present more complicated API. I kinda like XML (!), but there is no point pretending that using it is as simple as JSON.

I think that depends what you mean by "using it".

XML can convey a lot more semantic meaning than JSON ever will, and standardisation of things like XPath, DOM, XSLT, etc provides a lot of power when working with XML documents.

With JSON, essentially everything is unknown. You can't just get all child nodes of an object, or get all objects of a certain type, using standard methods. You need to know what object key 'child' nodes are referenced by, or loop through them all and hope that what you find is actually an array of child nodes, and not e.g. an array of property values. Finding all objects of a given type means knowing how the type is defined, AND the aforementioned "how do i get child nodes" to allow you to traverse the document.

Of course that assumes what you have is a document, and not just a string encoded as JSON. Or a bool/null.

My point is, the tooling around XML is very mature. "Use" of a data format is a very broad topic, and covers a lot more than just "i want to get this single property value".

Re: JSON Feed

#179

Post by [deleted] »

zeveb wrote: post #76

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html " Hello, world! ") (url https://example.or…

[deleted]

Re: JSON Feed

#180

Post by eriknstr »

mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

Absolutely agree about the MIME type.

Someone filed an issue and created a pull-request for this after you wrote this comment.

https://github.com/brentsimmons/JSONFeed/issues/22

https://github.com/brentsimmons/JSONFeed/pull/23

I hope they will merge it.

Post reply on HN