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

141–150 of 225 posts

Re: JSON Feed

#141

Post by mindcrime »

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…

The thing that http://activitystrea.ms got right was the realization that copying content into a feed just ends up diluting the original content formatting, so instead it just contains metadata and points to the original source URL rather than trying to contain it.

It's a shame that ActivityStrea.ms hasn't had more uptake. We've added support in our enterprise social network product and think it enables some cool scenarios. But unfortunately too few other products support it these days.

Re: JSON Feed

#142

Post by eric_the_read »

smilbandit wrote: post #132
eric_the_read wrote: post #112

A few thoughts on the spec itself: * In all cases (feed and items), the author field should be an array to allow for feeds with more than one author (for instance, a podcast might want to use this field for each of its hosts, or possibly even guests). * external_url should probably be an array, too, in case you want to refer to multiple external resources about a specific topic, or in the case of a linkblog or podcas…

I was thinking that all the urls and images should have been in arrays.

Probably, but I think the goal there is to have something that you can display on a summary page with a list of items or episodes, where there's just an icon for each (and a banner image for the background or header or some such), for which purpose I think a single image is fine (I totally get your wanting more than one, though, and I'm happy to be wrong here).

Re: JSON Feed

#143

Post by cyphar »

SamBam wrote: post #104
mstade wrote: post #97

Earlier quoted context omitted.

So we can ditch media types altogether then? What's the point of having actual contracts if all we need is a hand shake and a wink? We're not talking about malformed data here, that's something different entirely and yes – it happens all the time. We're talking about calling a spade a spade. If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. Granted, it…

I'm not sure what you're arguing. JSONFeed is JSON, unless I'm missing something, just JSON that matches a specific schema. If I'm pulling JSON from any API, I expect it to match a certain schema. If I expected { "time": 10121} from a web API they send me "4", then sure, that's valid JSON, but it doesn't match the schema they promised me in the API. Something that's JSON should be marked JSON, even if we're expecting…

> Something that's JSON should be marked JSON, even if we're expecting it to follow a schema.

That's what the +json type suffix is for. I wonder how many people in this thread actually have read the mediatype RFCs, because they definitely don't encourage using mediatypes in the way you're describing.

The whole point of mediatypes is to make it possible to distinguish schemas while also potentially describing the format that the schema is in.

Re: JSON Feed

#144

Post by pfranz »

mindcrime wrote: post #78
pfranz wrote: post #47

Earlier quoted context omitted.

Part of me is with you. But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. I think with something like feeds there's the possible benefit of becoming a 'hello world' for frameworks. Many frameworks have you write a simple blogging engine or twitter copycat. I don't think I've ever see…

But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML - including Atom - in years. But I admit that other platforms might not have the same degree of support.

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 in other languages I've used had similar brittleness when dealing with xml. I might be biased because working with xml in an editor it's difficult to validate visually or grok in general when used in practice.

[1] http://python-guide-pt-br.readthedocs.io/en/latest/scenarios...

[2] https://untangle.readthedocs.io/en/latest/

[3] https://github.com/martinblech/xmltodict

Re: JSON Feed

#145

Post by toyg »

hboon wrote: post #103
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…

FWIW, This is by Manton Reece and Brent Simmons. And Simmons is known (among other things) as the creator of NetNewsWire which has been around for more than 15 years. He does know a bit about Atom and RSS feeds. https://en.wikipedia.org/wiki/NetNewsWire

One has to wonder whether Simmons is just trying to revive the old RSS ecosystem. "What do developers like these days, JSON? Let's do RSS in JSON!" ... This does not help.

The real challenge these days is to replicate the solutions Facebook and Twitter brought to feeds (bidirectionality and data-retention in particular) in a decentralised manner that could actually become popular. Simply replicating RSS in the data-format du jour is not going to achieve that.

Re: JSON Feed

#146

Post by wcummings »

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.

No, we don't. This doesn't do anything except break compatibility.

Re: JSON Feed

#147

Post by toyg »

ttepasse wrote: post #119

Shortly after RSS 0.9 came out RSS 1.0 reformulated the RSS vocabulary in RDF terms. Of course the modern (sane) successor to RDF/XML is JSON-LD. So I'm hoping for JSON-LD Feed 1.1 and a new war of format battles. Maybe we can even get Mark Pilgrim out of hiding!

Someone should open a social network for feed-wars veterans.

More seriously, it's sad so to see that almost 20 years later, the dream of a decentralised and bidirectional web is in even worse shape than it was back then.

Re: JSON Feed

#148

Post by Communitivity »

It is worth pointing out that there is a relevant W3C Recommendation "JSON Activity Streams", https://www.w3.org/TR/activitystreams-core/ . I'm not saying JSON Feed is worse, or better. I am saying that I think JSON Feeds adoption requires a detailed comparison between JSONFeed and JSON Activity Streams 2.0.

Re: JSON Feed

#149

Post by thousande »

CharlesW wrote: post #16
skybrian wrote: post #7

Earlier quoted context omitted.

RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.

> RSS is sometimes ambiguous and there's a lot of variation. I've written a reasonably-popular podcast feed validator, and I don't understand either of these criticisms. Mind elaborating?

Not been writing XML parsers, but I remember Nick Bradbury the creator of the FeedDemon fame wrote about it a lot 'back in the days',

* https://nickbradbury.com/2006/09/21/fixing_funky_fe_1/

* http://nick.typepad.com/blog/2004/01/feeddemon_and_w.html

* https://en.wikipedia.org/wiki/FeedDemon

Re: JSON Feed

#150

Post by mstade »

DougWebb wrote: post #129
mstade wrote: post #97

Earlier quoted context omitted.

So we can ditch media types altogether then? What's the point of having actual contracts if all we need is a hand shake and a wink? We're not talking about malformed data here, that's something different entirely and yes – it happens all the time. We're talking about calling a spade a spade. If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. Granted, it…

If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. That's not a valid argument, because JSON is just a serialization format for an arbitrary data structure. You can't throw any arbitrary data structure at any program that accepts data and expect it to be able to accept it. Every program that accepts input requires that input to be in a specific format,…

Aww that's not fair – if you're going to quote then don't cherry pick and remove the relevant bits.

> If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. Granted, it probably won't be a very interesting program precisely because JSON is just generic data without any meaningful semantics.

(Emphasis mine.)

By doing this you're just reinforcing my argument that just parsing any ol' plain JSON won't make for very interesting programs. JSON is just plain dumb data, it doesn't tell you anything interesting. There may be additional semantics you can glean from a document than just its format (HTML is pretty good for this, but oddly enough not a very popular API format) if there are mechanisms to describe data in richer terms – but JSON has none of these. Yet this spec says you should serve this as just plain ol' boring JSON.

> And aside from programs that make strict use of XML schemas, they pretty much all use the handshake-and-wink method for enforcing the contract.

This is just not true. Case in point: web browsers – arguably one of the most successful kind of program there ever was, with daily active users measuring in the billions – make heavy use of meta data including media types to determine how to interpret the input. Not just by way of format (i.e. media type) but also by way of supplemental semantics (e.g. markup, micro formats, links.)

> My take on the author's approach is that the content-type is specifying the syntax of the expected input, and the documentation specifies the semantics and details of the data structure.

Which could and should be described in a spec, with a corresponding IANA consideration to include a new and specific media type in the appropriate registry – not by overloading an existing one.

Post reply on HN