Comments on: JSON feeds http://www.codedread.com/blog/archives/2006/01/31/json-feeds/ Wed, 17 Mar 2010 03:27:14 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: shr3kst3r http://www.codedread.com/blog/archives/2006/01/31/json-feeds/comment-page-1/#comment-367 shr3kst3r Tue, 09 May 2006 00:10:53 +0000 http://blog.codedread.com/?p=219#comment-367 I wrote up a quick article on converting RSS feeds to JSON using PHP. You might find it interesting. It is quick and dirty, but it might be useful for a mash-up. http://www.engrowe.com/?p=67 I wrote up a quick article on converting RSS feeds to JSON using PHP. You might find it interesting. It is quick and dirty, but it might be useful for a mash-up.

http://www.engrowe.com/?p=67

]]> By: Geir Aalberg http://www.codedread.com/blog/archives/2006/01/31/json-feeds/comment-page-1/#comment-366 Geir Aalberg Thu, 09 Mar 2006 16:40:32 +0000 http://blog.codedread.com/?p=219#comment-366 > it would be great if someone wrote some generic code that would convert an arbitrary > XML document/node into the equivalent JSON fragment "Arbitraty" is a pretty dauntint task (given that XML is a pretty complex data structure, especially using namespaces), but XSLT should be as good a tool as any. Plus, you can even do that directly in the browser. > it would be great if someone wrote some generic code that would convert an arbitrary
> XML document/node into the equivalent JSON fragment

“Arbitraty” is a pretty dauntint task (given that XML is a pretty complex data structure, especially using namespaces), but XSLT should be as good a tool as any. Plus, you can even do that directly in the browser.

]]> By: Jeff Schiller http://www.codedread.com/blog/archives/2006/01/31/json-feeds/comment-page-1/#comment-365 Jeff Schiller Tue, 31 Jan 2006 22:53:33 +0000 http://blog.codedread.com/?p=219#comment-365 Thanks, Johan - I didn't pick up your second post about this until now. Good stuff. Btw, I wasn't even considering a centralized XML-to-JSONP proxy, more of a here-is-some-code-free-to-use-and-copy type thing. Parsing XML is not hard in any language (just tedious) but getting the conversion proper might prove to be a little challenging ... and I'm lazy ;) Thanks, Johan – I didn’t pick up your second post about this until now. Good stuff. Btw, I wasn’t even considering a centralized XML-to-JSONP proxy, more of a here-is-some-code-free-to-use-and-copy type thing. Parsing XML is not hard in any language (just tedious) but getting the conversion proper might prove to be a little challenging … and I’m lazy ;)

]]> By: Johan Sundström http://www.codedread.com/blog/archives/2006/01/31/json-feeds/comment-page-1/#comment-364 Johan Sundström Tue, 31 Jan 2006 22:33:18 +0000 http://blog.codedread.com/?p=219#comment-364 You probably noticed my <a href="http://ecmanaut.blogspot.com/2006/01/jsonp-why-how.html" rel="nofollow">in-depth reply article</a> about these things, but here is a more direct digest I wrote up first prior to making it an entire article: 1: Naming issues are the same for JSON as for any XML dialect; the day your favourite data providers breaks backwards compatibility with the RSS format they previously committed to, your application breaks. It can be argued that widely adopted schemas such as RSS and Atom are safer bets, but IMO it's a moot point. As soon as you use somebody else's data, you are at their mercy of still making it available to you in what format they picked. 2 & 3: Overcoming the same origin policy browser security model being the main point an strength of JSONP (vs XML), yes, you point your script tag at the enemy and are at their mercy of not giving you any other side effects you did not bargain for. If you don't trust your feed not to send code with side effects, use either need elevated privileges so you can fetch content via XMLHttpRequest, to use a JSON parser rather than eval. The JSON site has one in javascript, but I'd opt to use some server side script to process and cleanse the feed first if I was in this situation. In which case your choice of picking up just any feed at all and reformatting it as JSONP would be the solution most close at hand. 4: A generic XML-to-JSONP proxy is a good idea in theory. Chances are it might be as useful to white as to black hat hackers, though I haven't given it much thought. The "open proxy" idea might not be much of a problem as it's just about reading data, though it might swamp the script and site with traffic. :-) The way I see it, making JSONP feeds for external consumption is really just interesting when you invite the wide public to innovate around your data. If you don't, why bother much about it at all? You probably noticed my in-depth reply article about these things, but here is a more direct digest I wrote up first prior to making it an entire article:

1: Naming issues are the same for JSON as for any XML dialect; the day your favourite data providers breaks backwards compatibility with the RSS format they previously committed to, your application breaks. It can be argued that widely adopted schemas such as RSS and Atom are safer bets, but IMO it’s a moot point. As soon as you use somebody else’s data, you are at their mercy of still making it available to you in what format they picked.

2 & 3: Overcoming the same origin policy browser security model being the main point an strength of JSONP (vs XML), yes, you point your script tag at the enemy and are at their mercy of not giving you any other side effects you did not bargain for. If you don’t trust your feed not to send code with side effects, use either need elevated privileges so you can fetch content via XMLHttpRequest, to use a JSON parser rather than eval. The JSON site has one in javascript, but I’d opt to use some server side script to process and cleanse the feed first if I was in this situation. In which case your choice of picking up just any feed at all and reformatting it as JSONP would be the solution most close at hand.

4: A generic XML-to-JSONP proxy is a good idea in theory. Chances are it might be as useful to white as to black hat hackers, though I haven’t given it much thought. The “open proxy” idea might not be much of a problem as it’s just about reading data, though it might swamp the script and site with traffic. :-)

The way I see it, making JSONP feeds for external consumption is really just interesting when you invite the wide public to innovate around your data. If you don’t, why bother much about it at all?

]]> By: Rob http://www.codedread.com/blog/archives/2006/01/31/json-feeds/comment-page-1/#comment-363 Rob Tue, 31 Jan 2006 15:49:32 +0000 http://blog.codedread.com/?p=219#comment-363 I read Douglas Crockford's thing on JSON a while back and I didn't think too much of it. It's a handy notation when everyone's transforming their XML into JS objects anyways, but I don't think it belongs at that layer. It's too much like arbitrarily executing anything you're handed. I read Douglas Crockford’s thing on JSON a while back and I didn’t think too much of it. It’s a handy notation when everyone’s transforming their XML into JS objects anyways, but I don’t think it belongs at that layer. It’s too much like arbitrarily executing anything you’re handed.

]]>