Let's do away with the doom and gloom: In spite of recent context-deprived accounts, WordPress isn't anywhere near ditching any of its feed formats. But what is all this talk about removing feeds from our favorite blogging tool? Let's have a rational look...
WordPress currently supports four standard feed formats for syndication: RSS 0.92, RSS 1.0 (aka RDF), RSS 2.0 (aka RSS2), and Atom 0.3. All of these feeds are at least vague implementations of XML, and allow applications (feed aggregators) to gather data about your posts without actually visiting your site. This can be done because these formats are machine-readable - that is, a computer/server can be configured to automatically visit your feed and parse out the data that it provides into usable chunks.
There are certain problems with the feeds that WordPress provides, and whether these really are problems depends on your perspective. But let me tell you what I see from a coder's point of view, and why you should consider listening to my argument.Each of the feeds that WordPress provides is supplied by a distinctly separate script. Essentially, the inner workings of WordPress churn on each request and regurgitate a raw spew of data representing the last few posts that you've written. Then the script that you've requested - be it RSS, RDF, or Atom - figures out how to format that raw data into something that looks like a feed.
At it's core, the problem is that these files are not easily maintained because they are separate. Why is this?
Every time you want to add functionality, like using a true GUID (Globally Unique ID - An identifier that is unique for each post in a feed), you need to change not just one file, but four.
When WordPress 2.0 was released, the approved/standard method of looping through each post was augmented. As such, all four feeds should have been updated with this new method to ensure that they are up to date. Were they all updated? No.
In fact, it has been a month since the last update to any of the feeds, in which a small glitch with a GUID was updated. (It was updated in other feeds, but not the one that was missed.) Before that, none of the feed scripts had been updated for four months. Surely software that has seen a major revision in that time should have had some review in this area. Maybe it was perfect. I'm not sure, but that seems strange to me.
People have said that RDF and RSS 0.92 are "simply too old", and maybe that's not fair. Some formats are being actively developed, but since our little blog software development world doesn't seem to keep up with those innovations, we don't see any benefit. Some folks would like to see Atom support upgraded from 0.3 to 1.0, and I am among them. It seems a disservice to WordPress to allow these feed formats to languish in disrepair, whether they are superceded by newer formats or not.
A seemingly separate issue: A suggestion that I agreed with on the wp-hackers mailing list earlier this month was additional support for comment metadata, including transferring comment handling into a centralized API. Currently, if you want to access comment information from inside plugin code, there isn't an efficient method to get it apart from requesting it directly from the database. As a result, no filters can be applied to that information, and none of the information comes out of any cache, so it's very difficult to write good, efficient plugins that affect comments.
Likewise, dealing with categories directly is a programmatic problem. Sure, you can do it, but it involves an arcane process that is best not attempted by any but veteran plugin developers. Function accessors to this data would prove an immense improvement for plugin development, if not for general overall efficiency and readability.
Making these changes is a good idea, but would affect large sections of code. It's not something that would happen overnight. It could not be planned for the upcoming 2.0.1 service release, and I only suggested it as a future enhancement. Nonetheless, feeds may be significantly affected by these changes.
Changes in significant areas of the software such as these would require exponentially significant testing. And as might have been noticed during our pains from the 2.0 release, WordPress could stand to have a bit more thorough testing generally. It doesn't need the strain of testing on formats that we don't even have an developer advocate strong enough to volunteer for coding and testing. Not only would someone have to adopt each of the four feed files, but we would need testers to focus on the changes in those areas. I don't see enough people who care - Maybe you're out there?
In that vein, the suggestion was proffered that to reduce some of the development load we should retire some of the feed formats that aren't as well used. That way, we can concentrate on perfecting the feeds that we do offer, improving the architecture in general, and opening up development to others who could supply their own feed formats. Sure, we who agreed this was a good idea were looking at the feeds as a method for a site owner to syndicate his site - not as a way for services to scrape data from your blogs.
One of the main complaints that I've heard is that removing RDF would cripple services that rely on the data it provides; that RDF is somehow more data-packed than the other formats available in a base install. I'm not sure how this is possible considering that they all are served the same data, but that's irrelevant.
WordPress is at its core blogging software. It's target user is a blogger. Do most bloggers know that they're publishing their data in feeds that are being scraped by services who would be mad if those feeds were suddenly cut off? I'm not sure what service requires one of the feed formats we're suggesting for retirement; one that can't use one of the other formats. And as a blogger, are you really concerned about those services that you didn't even know existed? I, for one, am unnerved that my data would be used that way, and look forward to turning RDF off on principle.
Besides that, nobody is suggesting that WordPress be restricted from producing RDF or any other of the feed types. It is good design to consolidate the method of producing feeds to reduce the overall code size, but that implies better, more flexible architecture. A new architecture would allow the production of additional even more robust feeds that the current architecture doesn't support; something that we could do via plugin that we would have a hard time doing now. And certainly, just as with the geographic coordinate funtionality that was removed from WordPress 1.2 for 1.5, a plugin would be available upon release to reinstitute those feeds for those who wanted to keep them.
I've heard people say essentially, "It ain't broke, don't fix it." Maybe not, but if we don't fix it when we update other parts of WordPress, then it surely will break. Let's fix it right and plan ahead to make it better instead of patching it all up piecemeal.
And as far as bogus theats of the Semantic Web people skipping out on WordPress for omitting a feed format are concerned, I can't believe that anyone could find as flexible a product for producing the needed feeds as WordPress, even if WordPress had never produced RDF. (Hey, isn't Semantic Web a pipe dream anyway?)
So where does that leave us? Lesser-used feeds should be retired from WordPress to benefit development of the feeds we keep and the coverage of code that needs testing. Having core code that all works is more important than making sure any pet formats are included.
In the end, we've only heard the word of one of the Automattic guys on the issue, and he's not too enthusiastic about it. I've learned that in order to get anything major done in WordPress you need two things: Running code and commit dev support. We "anti-RDF" people have neither so far, but we're still talking about a solution that works best for everyone. So let's not all panic.
It sure would be helpful if people who care about these formats would step out and take care of them, though.
See also: http://groups.yahoo.com/group/rss-dev/message/7327
I'm by no means an expert on Wordpress code or XML, but doesn't Feedburner provide a service whereby whatever feed you give it is output in any of the popular feed formats depending on what the client can accept?
Could something like that be accomplished with Wordpress alone, so that the maintenance of only one core feed is required, with included bits to transform it as necessary?
Then again, that would probably get too complex and again suffer un-updatedness.
Why not just take out the 0.92 feeds if the SemWeb hackers are having sentimental issues about the 1.0 ones? Lashing out about whether the SemWeb is a pipe dream is not the way to resolve the issue.
Also, you'll have to admit, the issue is mostly psychological (cleaning out the cruft). I'm all for it, but it's not really a pressing technical issue, right? Might as well deprecate first.
Suggestion: make new bug to deprecate 0.92. Make seperate bug to deprecate 1.0
Overhauling the feed system could be of benefit to everyone. It's not going to be enough to say simply, "Let's remove that one that everyone can agree is worthless." They'll all be out of date after we make other fixes. They're mostly already out of date.
I'm reading this as a fishing expedition for rationalizing what, in reality, is just a loss of interest by the WP developers for feed support.
And that doesn't mean I dispute it. Sure, scraping is crummy. And dedicating work toward providing four different flavors of syndication makes about as much sense as outputting four different versions of your site (HTML, WAP, SHTML, etc.).
Furthermore, I'm not a particularly big proponent of feeds anyway; I don't subscribe to any. I display a link to just RSS2 on my blog; if anyone wants the others, they should know how to detect them. My feeds get plenty of traffic, but I'd guess a huge chunk of that is scraping activity.
Still, this is basically a cynical approach to abandoning a feature, and you're trying to mask that through external justification. Reminds me of a similar arc when per-post pingbacking was dropped from 1.5. Basically gives WP development too much of a clubby feel.
Option one: combine and re-write code as necessary for centralized body of functions that is easy to control outputs nice feeds. (Not likely to happen, I don't much like this one.)
Option two: Kill, kill, kill. (I like this one much better)
You can't please everyone all the time. As progress happens, eventually something will have to be left behind. It is probably a good idea to overhaul the feed system, and the idea of making a central source that can be tweaked to fit the different formats is also nice. However, it's going to get out of hand as time goes on if everything has to be 100% backwards compatible forever. Eventually, things just won't work for people who use stuff that adheres to ancient standards. Rather than abandoning the feature entirely, maybe this is something that can go out to the community that wants it so badly. If they want the functionality, they can write it in.
Semantics: I think that your suggestion that WordPress is a blogging software at its core misses the boat very slightly. Yes, WordPress is aimed at a target audience of bloggers. However, if you extend your scope a bit, you will see that bloggers use the software to communicate ideas to readers; and if readers can't read the content that bloggers produce, there is a risk that those readers will go elsewhere, which may in the long run pull your blogging audience away from WordPress.
On the other hand, trying to support every conceivable way of supplying content will only introduce bugs and compound complexity.
Here's an off-the-cuff suggestion: why not put the feed generation stuff into plugins and take it out of the core product? The core product could then move ahead without concerning the feed generators, and if anyone seriously cared about the feed generator plugin for format x, they would have an incentive to maintain it.
As for me, I don't really care about the feeds. I've tried various RSS feed readers and to be honest I don't get it. I've got a bunch of weblogs in my bookmarks folder which don't provide RSS, so if I want to read 'em I use the browser. So similarly, I'm not overly concerned by burdening _my_ audience with the need to use a web browser to read _my_ content.
Why not do the same thing with feeds that was done with geo coordinates? I'm sure if someone really cares about a certain format, they'd be willing to maintain a plugin for it. I'd be more than happy to install a plugin for each feed format I want to provide.
Bloggers use feeds to communicate ideas, sure. And I ask in what way are the suggested limited feeds insufficient for doing so? All feed types are supplied the same data by the WordPress core - the idea that one feed type has more WordPress data in it is silly.
It's hard to believe that I didn't communicate the following point in the screed above.
Yes. That's exactly what I'm suggesting: Replacing the existing feed-generating code modules with something centralized that probably has fewer feeds. The new centralized module would make it easier to create plugins to add new feeds. New feed plugins would be readied at release time to support the feed types that were removed from the core.
And to clarify that even further - No, the plugins would not be WordPress-supported, and would not be distributed with WordPress. They would be personal efforts by developers with a vested interest in the formats they supply. They can only be better than what we currently supply, and natural selection will allow unused/unsupported feeds to fall off.
Rational look? Ok, you do make some fair points here, but let me just get these bits out of the way first: I don't see any "bogus threats" in my post to which you link. All I said was : "...for a developer working with SemWeb systems, they’ll probably be considerably less likely to choose WordPress if it lacks any RDF support". Your "pipe dream" remark isn't particular rational either (pipe dreamers like IBM, Oracle, HP, Adobe... are working on Semantic Web technologies). Given the increasing proportion of people who read blogs through syndication tools, I'm also little surprised to read "Some formats are being actively developed, but since our little blog software development world doesn't seem to keep up with those innovations...".
Regarding "strain of testing on formats", test systems are already available, in particular the Feed Validator and the W3C's RDF Validator. (In my own use-often FireFox tab folder I've got my own blog's output linked to these as well as the HTML Validator).
In answer to "...that RDF is somehow more data-packed than the other formats available in a base install. I’m not sure how this is possible considering that they all are served the same data". As the comment above suggest, it may be silly to say that one feed type has more WordPress data in it than another. But there is also the question of useful data. That isn't the same across formats. RSS 2.0 has known problems with silent data loss for a start. As you say it's not altogether relevant, but RDF/XML (e.g. RSS 1.0) *does* provide more data than most XML languages because it's defined in terms of the RDF (plus RDF Schema) model. For example, when you see an RSS 1.0 item element in a feed (I won't try the syntax here ;-), from the RDF interpretation you can determine that the rss:item is also an instance of rdfs:Resource. See also : RDF Primer.
"...as a blogger, are you really concerned about those services that you didn’t even know existed?" - this isn't something specific to feeds, it's the nature of the web. There are quite probably hundreds of HTML-based services (search engines etc) using your blog data that you aren't aware of.
Ok, your last point is well made: "It sure would be helpful if people who care about these formats would step out and take care of them, though.". If it will help continue support for RDF in WordPress, consider me stepped out.
[...] It's been proposed that WordPress drop RSS 0.92 and RDF as supported feed formats. This has caused a flurry of posts to the hackers mailing list, and no shortage of blog posts about it. [...]
Consolidating the code for feed generation in some APIs is the Right Thing!
Dropping support for some flavour of feeds isn't the way!
Many of us are happy if our blog content is syndacated (I have more readers via RSS than HTML), and I want to offer to my subscribers a wide range of feeds choice.
RDF is a different matter tahn other feed, but for the ones who really care (and understand what to do) about RDF the standard feed provided with WP is not the best.
So the way could really be to rely on plugins for providing every esotheric taste of feed, with those for RSS 2.0 and Atom 1.0 installed as default.
[...] Owen over on Asymptamatic has weighed in on the matter saying that he wouldn’t mind RDF / RSS 1.0 being dropped solely because of services which scrape you data via RDF. I’m not sure what service requires one of the feed formats we’re suggesting for retirement; one that can’t use one of the other formats. And as a blogger, are you really concerned about those services that you didn’t even know existed? I, for one, am unnerved that my data would be used that way, and look forward to turning RDF off on principle. [...]
[...] Luckily Owen Winkler is trying to pull back from this feed deathmatch. WordPress needs to handle comments, categories, and permanent links in a consistent way, regardless of the feeds it produces. Winkler is talking about the next generation of WordPress, while Coukouma’s patch only updates the existing Atom 0.3 template (for example, the patch does not create an Atom Comments Feed). [...]
I might not be a PHP expert, but I fail to see how removing useful functionality from Wordpress could possibly make it better!
[...] In a larger post about keeping the scripts that produce WordPress’s syndication feeds up-to-date, Owen Winkler says the following: Changes in significant areas of the software such as [comment- and category-focused APIs] would require exponentially significant testing. And as might have been noticed during our pains from the 2.0 release, WordPress could stand to have a bit more thorough testing generally. It doesn’t need the strain of testing on formats that we don’t even have an developer advocate strong enough to volunteer for coding and testing. Not only would someone have to adopt each of the four feed files, but we would need testers to focus on the changes in those areas. I don’t see enough people who care - Maybe you’re out there? [...]
Heck, all that, Owen, and no mention of the goofiness that is comment feed support. It's odd that WP outputs feeds in RSS0.92, RDF1.0, RSS2.0, and Atom0.3, but only outputs comment data in RSS2.0. [I think it was Alex who wrote the initial code.] Now, some feed is better than no feed, but shouldn't there be some symmetry here?
I'm all for somehow developing an API for this so that plugin support could be made. I'm with you---I'd probably shut off RDF support, but man, if it were pluggable, someone would have already done an Atom 1.0 plugin, and I wouldn't have to bitch and moan about the lack of Atom 1.0 support in WP2.0.
Why don't you just rip all the feeds out of WordPress and have RSS2 and Atom as active plugins. If anyone then wants to make and publish their own feeds they are welcome too and incoraged to publish them.
All this talk about feed support and how difficult it is to keep the code up to date. Tsk tsk tsk.
Why not keep a single, well documented XML export and use XSLT to convert it to the more esoteric feed types. XSLT is light years easier than PHP, particularly for anything as simple as converting between XML-based formats.
Peace out lads.
There are a few good reasons for not using XSLT:
1) Devs would still need to know PHP to power the XSLT engine, so why add that language at all?
2) Last I checked, installed XSLT support under PHP was not widespread.
3) XSL is probably even less known than javascript among WordPress developers, which is to say that maybe 3 people would know it.
4) XSL is "easier" than PHP? Uh, ok. I always thought it was a nonsensical pain in the butt; using attributes to define behavior best left to functions.