I've taken a look at the proposed API, what exactly is it helping us do? I saw the groups, but the only thing that I understood is that contributing to them would be advocating a need for an aggregation API, which frankly, I don't think is needed at all (I'm open to other opinions though if they're valid and convincing). Would the current 3 or 4 aggregation modules have been justified if they utilized an aggregation API? There is, however, one thing that I did see as very wrong. A module developer can't just throw away his work, create an alternative module, and leave things behind as if they've never been. Creating a module that everyone depends on is an ethical responsibility that needs to be transferred to someone who can manage it when the original author can't work on it anymore. What has been achieved with leech could have also been achieved by updating aggregator2 to become leech (albeit retaining its aggregator2 name) without neglecting its users. I'm trying to provide positive criticism here. Mistakes are done all the time, it's simply human nature. But let's make sure they aren't repeated, shall we? IMHO, we should make it compulsive that every module developer post to the mailing list before setting on a new module. This may prevent the catastrophe of so much repeated modules and repeated code. On 4/29/07, Ken Rickard <agentrickard@gmail.com> wrote:
(Half kidding. It would be great if all who work on aggregator stuff unify their efforts on such an API).
Already there. See http://groups.drupal.org/node/3528 (or the original post at http://drupal.org/node/130942).
Aron Novak's SoC project also addresses this, turning Aggregator module into an API with standard library for parsing, but opening up a pluggable architecture for other modules to replace/extend.
I believe that all the aggregator-type module authors are on board with the new API concept.
If you haven't read the proposed API, now is a good time...
- Ken Rickard agentrickard