> IMHO, we should make it [compulsory] that every module developer post to the<br>> mailing list before setting on a new module. This may prevent the<br>> catastrophe of so much repeated modules and repeated code.
<br><br>I would agree with this, and we're all guilty of not doing it. Especially the aggregator clones. I had no idea you were trying to upgrade Aggregator2.<br><br>That aside, the Aggregator API addresses two fundamental problems:
<br><br>1) Too many people duplicating work without coordinating. That's a recipe for two things: extra effort and security holes. More code to review means more code that doesn't get reviewed properly.<br><br>2) A core Aggregator module that doesn't let other modules call or extend its functions. Take a look at the 3 or 4 functions that I had to copy out of Aggregator module to get user-submitted feeds working for MySite. That's what started all this discussion.
<br><br>As to this point, I think you are definitely in the minority here, since most of the other module authors have weighed in on the proposal.<br><br>> I've taken a look at the proposed API, what exactly is it helping us do? I
<br>> saw the groups, but the only thing that I understood is that contributing to<br>> them would be advocating a need for an aggregation API, which frankly, I<br>> don't think is needed at all (I'm open to other opinions though if they're
<br>> valid and convincing). Would the current 3 or 4 aggregation modules have<br>> been justified if they utilized an aggregation API?<br><br>It will be much better for all Drupal users and developers if there is a common library of feed handler functions. Even better, that library would allow for the replacement / extension of those functions by other modules.
<br><br>From a security perspective, it is infinitely better to have a single
library for feed acquisition and validation, just like we have with
file uploads. In fact, that's the perfect comparison -- all the file security pieces are hanbdled by file.inc, not contrib module developers. (We might even deprecate aggregator.module for aggregator.inc, but that's a separate issue.)
<br><br>There will still be room for those 3 or 4 contributed modules to add features, but their code weight will be much lower, since common functions will be handled in Aggregator.<br>
<br>
The proposed work is moving towards fixing core Aggregator because that's where the best, most stable benefit is for the largest user base.<br><br>Providing upgrade paths for folks using dead modules is noble, and best addressed, I think, by some simple data conversion scripts. We can possibly include those in Aron's project....
<br><br>- Ken Rickard<br>agentrickard<br><br>