[wp-trac] [WordPress Trac] #25639: Implement a JSON feed using rssjs.org spec

[WordPress Trac]

#25639: Implement a JSON feed using rssjs.org spec
------------------------------------+-----------------------
 Reporter:  nacin                   |       Owner:  pento
     Type:  feature request         |      Status:  assigned
 Priority:  normal                  |   Milestone:  3.8
Component:  Feeds                   |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+-----------------------

Comment (by aramzs):

 Some thoughts regarding this ticket as someone working with a lot of feeds
 internal and external to WordPress. I'm in the process of working with the
 Center for History and New Media at George Mason Univerity
 [https://github.com/PressForward/pressforward to build a WP plugin that
 parses, interprets and broadcasts RSS feeds] and is getting set up to deal
 with other types of feeds.

 I think there are some important considerations that make this a
 worthwhile project to move forward on sooner rather than later, especially
 for WordPress.

 Right now the field for RSS is wide open. Google Reader dropped out of
 existence, but nothing has filled the gap completely. This means there is
 a big opportunity for the content providers to push the next generation of
 tools to use new and better formats. No one is better placed to do so than
 WordPress, but that window may only be open for so long.

 Further, RSS as a spec is chaotic, there are a lot of namespaces out there
 and no place that lists them all effectively, nor any platform that
 implements all, or even the most important ones. There are things that RSS
 needs to be better, more modern, and more useful to anyone who wants to
 use it in any way beyond some really basic reading.

 I've been doing a lot of work with interpreting and generating RSS and
 [http://pressforward.org/ we've been collecting feedback from the authors,
 academics and readers using our plugin]. There's an opportunity here to
 extend beyond the basics of RSS2.0 and make it better.

 It's even more attractive because the available processes that handle RSS
 and process it, even SimplePie (used in WP itself), are way heavier,
 cumbersome and difficult to extend that the same type of process through
 JSON. Parsing any large number of feeds is a huge load on any system and
 the biggest challenge for RSS reader tools.


 > Imagine switching out the library you use for grabbing a feed from an
 expensive XML-based one to a lightweight JSON one, maybe changing a
 variable name or two for things that are namespaced (which doesn't make
 sense to try and duplicate, because there's no XML-style extensibility
 model we're trying to build in), and then the rest of your code runs
 exactly the same. With a callback you could even do it entirely client-
 side and cross-domain.

 This is exactly the opportunity. If you build it, they will come. All
 these fledgling RSS services would love a significantly lighter tool in
 JSON parsing, they just don't have anyone to use it on. If implemented,
 this would be the push to develop these tools, I know I would.

 Beyond all that, this is WordPress's opportunity to push for additional
 things in the standard that are needed by users, but not supplied. Things
 that are available in a rainbow of disconnected protocols.

 I think WordPress has a golden opportunity to push this forward right now
 and we should grab it.

 A short list of items that would make standard RSS better:
 * per-item authors (because think of how many blogs have guest authors or
 multiple users)
 * per-item copyright/creative commons statements
 * per-item original/syndication source
 ([http://googlenewsblog.blogspot.com/2010/11/credit-where-credit-is-
 due.html Google does it], and it is needed, because aggregation is now
 standard blog behavior)
 * OpenGraph data, especially featured image, for readers like Feedly or
 aggregation tools like PressForward, which have to manually walk through
 feed items looking for images, not an easy or lightweight behavior.
 * a separation between taxonomies (tags, categories, or custom taxonomies
 defined on object)
 * sharing data like that described in Activity feed.
 * Abandoning 'description' and calling it what it is used for, an
 'excerpt'
 * Standard use of 'content'

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25639#comment:24>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software