&gt; IMHO, we should make it [compulsory] that every module developer post to the<br>&gt; mailing list before setting on a new module. This may prevent the<br>&gt; catastrophe of so much repeated modules and repeated code.
<br><br>I would agree with this, and we&#39;re all guilty of not doing it.&nbsp;&nbsp; Especially the aggregator clones.&nbsp; 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.&nbsp; That&#39;s a recipe for two things: extra effort and security holes.&nbsp; More code to review means more code that doesn&#39;t get reviewed properly.<br><br>2) A core Aggregator module that doesn&#39;t let other modules call or extend its functions.&nbsp; 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.&nbsp; That&#39;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>&gt; I&#39;ve taken a look at the proposed API, what exactly is it helping us do? I
<br>&gt; saw the groups, but the only thing that I understood is that contributing to<br>&gt; them would be advocating a need for an aggregation API, which frankly, I<br>&gt; don&#39;t think is needed at all (I&#39;m open to other opinions though if they&#39;re
<br>&gt; valid and convincing). Would the current 3 or 4 aggregation modules have<br>&gt; 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.&nbsp; 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.&nbsp; In fact, that&#39;s the perfect comparison -- all the file security pieces are hanbdled by file.inc, not contrib module developers.&nbsp; (We might even deprecate aggregator.module for aggregator.inc, but that&#39;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&#39;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.&nbsp; We can possibly include those in Aron&#39;s project....
<br><br>- Ken Rickard<br>agentrickard<br><br>