My module's architecture is already functioning as an API. Upon installation, it creates a vocabulary that contains terms such as (RSS20, RDF10, ATOM10). These terms are attached to the feed node type. When a user creates a feed, he has to specify one of these terms to go with the feed. He can create extra terms (this is where the expandability comes in!).
<br><br>Now that he created his feed. He needs to create a file associated with the term he chose, the file, such as RSS20.inc will be passed a simpleXML object and the feed object. My module handles reading the URL string and loading it into a simpleXML object, then passing it to the feed handler, in this case,
RSS20.inc, the feed handler loops over the items and extracts specific fields such as title, body, time, image_url. This is where the XML specific extraction occurs, then it calls another (API?) function inside my module called "add item" and passes all of the extracted data to it. Among the passed data it can specify an unlimited number of (extracted) terms and even new (extracted) vocabularies to group this item under. If the term already exists, it will go under it, else, it will create it and go under it (auto-taxonomy).
<br><br>My API function can also be passed one image URL per item, automatically extract it, insert it as an image node, and attach it to the item node.<br><br>What if we have a custom XML formatted URL to parse? Some XML format called XYZ? We create a new term called XYZ, add it to my aggregation vocabulary, add a file in the feed_handler sub folder called
XYZ.inc, my module retrieves the URL and loads it in a simpleXML object, passes it to XYZ.inc, which does the special extraction, and passes the results to my "add item" function which creates a node, and an image node if a URL was passed in by
XML.inc, and wala, that's how easy it is to expand it. Nil code duplication, but I'm sure there are infinite ways to extend it.<br><br>This provides the ability to parse any new formats using what I hope is a simple API. And is in need of everyone's help to make perfect. As a beginning, we can start by removing the PHP5 specific code (or to provide conditional alternatives to be precise?). My API/module is composed of the following methods :
<br><br>function aggregation_get_URL($url, $username = NULL, $password = NULL, $feed = NULL,<br> $feed_etag = NULL, $feed_last_modified = NULL)<br><br>function aggregation_get_XML($string, $feed = NULL)<br><br>function _aggregation_<term-name>_parse($feed_XML, $feed)
<br>** (present in file <term_name>.inc) making it a clean add-on. I thought of making this a new hook_aggregation_term_name or something??? Just some thoughts... **<br><br>function _aggregation_add_item($title, $body, $teaser, $original_author, $feed,
<br> $additional_taxonomies, $timestamp = NULL, $original_item_url = NULL, $guid = NULL,<br> $image_array = NULL);<br><br>What does the user who wishes to extend this module do? He adds one term and one file that holds one function. The only code he writes is specific format extraction code.
<br><br>Now to one important last issue, I would be extremely grateful for a sponsor to my module, weather it goes to core or not. I have 6 wonderful feature requests that make my fingers tingle just thinking about implementing them. But the times on my side, they are a changin', and not to the better I'm afraid. Regardless of weather my module is sponsored or not, I'm telling everyone who uses it that they should rest assured I will keep it in tip-top shape. It's become so solid that I've not received a bug-report for nearly two weeks, but rather 6 feature requests. Two of which are BIG. I've received a number of thank yous which has made this well worth the effort. If someone can help me by sponsoring it so I could actively continue development I would be extremely grateful.
<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Boris Mann</b> <<a href="mailto:boris@bryght.com">boris@bryght.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/1/07, Dries Buytaert <<a href="mailto:dries.buytaert@gmail.com">dries.buytaert@gmail.com</a>> wrote:<br><br>> My aggregator module too ... ;-) Personally, I think we need to fix<br>> this in core but hey, we've been saying that for 2 years now, and so
<br>> far, I've seen very few aggregator module patches. Boris did a good<br>> job outlining some of the work it takes, it's just a matter of<br>> implementing some of these proposals. Anyone willing to work on
<br>> this? We can do this one patch at a time so it not particularly<br>> complicated or time-consuming ...<br><br>I wanted to point out that Bill from Achieve Internet updated a bunch<br>and there are three ready for review already, including fixing PHP
<br>notices, the return (!!) of "blog this", and entity / tag stripping of<br>titles. See <a href="http://groups.drupal.org/node/3538">http://groups.drupal.org/node/3538</a> for a few more to look<br>at.<br><br>
All I'm doing is some bug gardening on the issue queue: feel free to<br>do some review of issues (I've got some favorites in there from '05!)<br>and then summarizing on the wiki.<br><br>Feel free to jump in, it's a good way to power level your core commit points :P
<br><br>--<br>Boris Mann<br>Office 604-682-2889<br>Skype borismann<br><a href="http://www.bryght.com">http://www.bryght.com</a><br></blockquote></div><br>