On PHPBuilder.com today there's a quick tutorial showing you how to build an RSS aggregator that can pull in RSS content and drop it into a MySQL table.

RSS stands for Really Simple Syndication. It is a Web format that allows website owners to distribute their latest and frequently updated content in a standardized way. RSS feed is actually an XML document that can be easily read by using RSS reader software or built-in functions in programming languages, such as PHP or Java. In this article, the focus will be on building a RSS aggregator in PHP.

They introduce the basics of an RSS feed - a specially formatted XML document with values for individual posts (like "title" and "link". They provide the SQL structure for the "article" and "feed" tables and the code to pull out each "feed" record, parse it and drop that into the "article" table for later consumption. They show two different methods for getting the content - one using file_get_contents and another using cURL.

If you're still interested in contributing your ideas and feature requests for a PEAR channel aggregator, Stuart Herbert wants to know (last call before the development starts).

There’s already been a sizeable response so far, but if you haven’t had your say yet, please head on over and leave a comment soon. I’ll write up a summary of the suggested requirements on Monday.

The idea behind the aggregator is to provide a single place for developers to look (besides the PEAR site, of course) for PEAR packages they might find useful. The key here is that the aggregator would be bringing together the independent channels out there and making them simpler to find. Feature suggestions so far include: showing where the library lives (like github or bitbucket), creating a proxy channel for a "single install" location and customized lists of a user's "in use" and "tracked" packages.

In his latest post Padraic Brady talks about an effort that's been put out there (by Stuart Herbert) to come up with a PEAR channel aggregator - something he fully supports.

Since we seem to like blaming the PEAR Group, and getting that ball kicked back to us, it’s time we did something useful. We’ve spent too much time ignoring PEAR as we grew apart from it with our frameworks, standalone libraries and custom plugin architectures. We’re making life harder for ourselves in doing so. Stuart Herbert has posted a short article to gather requirements for a Pear Channel Aggregator. I strongly suggest that interested PHP programmers drop by and add a comment with some suggestions/feedback.

Stuart's suggestion has already gathered some good comments and suggestions from all around the community including some mentions of efforts from the Symfony project to do something similar.

On PHPBuilder.com there's a new tutorial looking at using the SimplePie library to aggregate RSS feeds.

PHP developers are particularly lucky as a fantastic library named SimplePie not only offers the aforementioned features but also supports both RSS and Atom formats, multiple character encodings, and an architecture that makes integration with your favorite content management and blogging platforms a breeze. In this tutorial I'll introduce you to SimplePie, showing you how easy it is to create a rudimentary custom RSS aggregator using this powerful library.

He helps you get SimplePie installed (downloaded and unpacked) pulling in both single and multiple feeds. There's no caching or storage included in the tutorial, but it would be recommended if you choose this as an option for everyday use.

Padraic Brady has written up a post on how he implemented conditional fetching (GET) as a part of the Zend_Feed component of the Zend Framework.

You see, by default, Zend_Feed is stupid. It will blindly drag in whatever RSS you point it at, parse it, present an accessible API (which is largely an abstract API across PHP DOM), and then merrily sit back while you are driven demented. There is a problem in blindly fetching RSS and parsing it - RSS feeds from a huge number of online sources only change rarely. The rest of the time the feed is unchanged.

The key is in the "Last-Modified" header data of the remote file (and ETag). He shows how to use this knowledge in a simple example - pulling data with a ZFBlog_Aggregate class and dumping the contents into a database table. This code checks the return status for a 304 ("Not modified") and closes out the connection if so. Otherwise it grabs the content and updates the database with the most recent fetch times to compare to the "Last-Modified".

In a new post to his blog today, Danne Lundqvist shares his method for creating a blog aggregator (in the style of the planet-planet sites) to re-aggregate all of the feeds back ou tinto one.

Lately I have begun to get more and more annoyed with my feed reader. I use a simple feed reader which lack most features except for subscribing to and reading feeds. The one thing that annoys me the most is that it can't aggregate several feeds into one feed. Yesterday I finally decided to scratch that itch.

His method uses the Zend Framework to accomplish the goal - and "the whole website logic (both model and controller) is about 200 lines of code". There's no exception or error handling in it, but it works and the Zend_Feed module works well to grab just about any kind of feed.

In a new post to his blog today, Danne Lundqvist shares his method for creating a blog aggregator (in the style of the planet-planet sites) to re-aggregate all of the feeds back ou tinto one.

Lately I have begun to get more and more annoyed with my feed reader. I use a simple feed reader which lack most features except for subscribing to and reading feeds. The one thing that annoys me the most is that it can't aggregate several feeds into one feed. Yesterday I finally decided to scratch that itch.

His method uses the Zend Framework to accomplish the goal - and "the whole website logic (both model and controller) is about 200 lines of code". There's no exception or error handling in it, but it works and the Zend_Feed module works well to grab just about any kind of feed.

In the continuing series on RSS files, DevShed has posted this new part with a focus on the "theoretical aspects" of developing an RSS file.

These aspects include things like examples of the elements it can contain, elements that are required for it to be a compliant RSS document, a look at the enhanced RSS functionality and structure (more information about the creator of the RSS embedded in the data), and even a look at what an aggregator is and what they would do with your RSS file.

Keep an eye out for the last installment in the series - a look at actually creating the RSS file from your data (probably from a database) and displaying it for the world to see.

In the continuing series on RSS files, DevShed has posted this new part with a focus on the "theoretical aspects" of developing an RSS file.

These aspects include things like examples of the elements it can contain, elements that are required for it to be a compliant RSS document, a look at the enhanced RSS functionality and structure (more information about the creator of the RSS embedded in the data), and even a look at what an aggregator is and what they would do with your RSS file.

Keep an eye out for the last installment in the series - a look at actually creating the RSS file from your data (probably from a database) and displaying it for the world to see.

Hasin Hayder has a new note on his blog today about a new site he's developed to aggregate the feeds from other PHP-related sites and blogs as well as a few on other topics as well.

FeedPHP is a free RSS aggregator which collects feed, parse and display the titles with a link back to the original source. The whole site is a single page with mod_rewrite tricks.

For performance, the contents are cached for several minutes, otherwise my site will be convicted for consuming excess bandwidth from those sites. Moreover, the site will be extremely slow for consuming remote contents frequently. Output buffering is used to serve contents quickly.

There is definitely tons of content here, but my only complaint is that it seems to load each section a bit slow, especially for cached data? Other than that, it's a great resource for an overview of what's happening in the PHP (and related) communities.