John<br><br>There is no &quot;offense&quot;, &quot;food chain&quot;, nor &quot;by the book crowd&quot;. Your choice of words <br>here does not reflect reality.<br>
<br>A bit of history here:<br><br>Agg2 was used by some site that Ashraf worked on, and the ugliness was <br>evident. Performance sucked big time.<br><br>So, Ashraf proposed an aggregator3, which is a successor of aggregation2. 
<br>The list here, rightfully so, objected to module2, module3, ...etc, and instructed<br>Ashraf to take over agg2 and rewrite it if necessary.<br><br>However, for reasons that Ashraf stated before (convincing for some, not for
<br>others) he named his module aggregation.<br><br>Back to APIs. As you said an end user cares less if there is an API or not, or if<br>the code is elegant or not, as long as it does the job. However, Drupal is an<br>ecosystem, not just a CMS. If an API for something evolves, it will get reused,
<br>refined, refactored and everyone wins. Look at FormAPI for example, and where<br>Drupal since 4.7 is. It is amazing.<br><br>An example from my own set of modules: I am the author of one of the first <br>voting modules for Drupal (nodevote). It did the job and many people use it. 
<br>Then Jeff Eaton came along and wrote the Voting API which is used for Vote <br>Up/Down, Fivestar, Simple vote, custom vote and&nbsp; Medium Vote.<br><br>I could have been overprotective and refuse to do it because of a NIH complex
<br>(not invented here). On the contrary, I know a good idea when I see it, and I <br>have been contemplating moving nodevote to Voting API for a year now, but<br>time does not permit it. There is some renewed interest in this, and it will 
<br>probably get done.<br><br>Conversely, Userpoints is a module that evolved from an application to an<br>API and is now used by many others modules (released and unreleased).<br><br>APIs make things easier for everyone, and it is good that people pool resources
<br>rather than cling to their own piece of code and be overprotective about it.<br><br>I now step down from the soap box.<br><br><div><span class="gmail_quote">On 4/30/07, <b class="gmail_sendername">John Bransford</b> &lt;
<a href="mailto:john@nashvillesnews.net">john@nashvillesnews.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ashraff wrote this
<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>I&#39;ve taken a look at the proposed API, what exactly is it helping us do? I<br>
<br><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&#39;t think is needed at all (I&#39;m open to other opinions though if they&#39;re
<br><br><br>valid and convincing). Would the current 3 or 4 aggregation modules have<br>been justified if they utilized an aggregation API?<br><br>There is, however, one thing that I did see as very wrong. A module<br>developer can&#39;t just throw away his work, create an alternative module, and
<br><br><br>leave things behind as if they&#39;ve never been. Creating a module that<br>everyone depends on is an ethical responsibility that needs to be<br>transferred to someone who can manage it when the original author can&#39;t work
<br><br><br>on it anymore. What has been achieved with leech could have also been<br>achieved by updating aggregator2 to become leech (albeit retaining its<br>aggregator2 name) without neglecting its users. </pre></blockquote>

<br>I wanted to put in my two cents.&nbsp; Ashraf is exactly right here.<br><br>&nbsp;I sponsored the development of Aggregator2 for a reason. The purpose was to create a publishing platform that could consume and display&nbsp; RSS content and had nothing to do with an API.&nbsp; I full well understand the difference so please save your lectures for someone else.&nbsp; None of the modules other than Ashraf&#39;s Aggregation module come close to providing the Aggregator2&nbsp; intended functionality for 
4.7x or 5.xx.&nbsp; <br><br>He&#39;s done the exact right thing here. &nbsp; I&#39;m sort of curious what the actual offense to the development process&nbsp; is supposed to be. I guess I&#39;m missing the issue totally as it seems to be that he added to the confusion by creating another option. 
<br><br>So what?&nbsp; <br><br>I suppose its a matter of your place in the food chain.&nbsp; His Aggregation module works and incorporates the best aspects of Aggregator2 and extends it in ways that are excellent.&nbsp; Api work has little to now end user or immediate application for working sites.&nbsp; It is a different concern.&nbsp; 
<br><br>If even one user has some need that is met by a solution like his Aggregation module then the effort was well worth it. But when the functionality is there and because he&#39;s already shown willingness to support the work an make instant and useful changes then I can see zero reason for even a murmur of complaint.
<br><br>The freedom of open source development is exemplifed by his ability to ignore the noise from the&nbsp; by the book crowd. (whatever the book de jour might be) and just get it done.<br><br>In fact it is the best answer to all the other aggregation for contented modules in my estimation and is likely to be the basis for any API extension.&nbsp; The testing and knowledge gained from putting it to use has been invaluable.&nbsp; 
<br><br>Thanks Ashraf<br><span class="sg"><br clear="all"><br>-- <br><br>Binserver<br><a href="http://Binserver.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://Binserver.com</a><br><br>
<a href="http://NashvillesNews.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://NashvillesNews.net
</a><br><br>(615) 349-8841
</span></blockquote></div><br><br clear="all"><br>-- <br><a href="http://2bits.com">2bits.com</a><br><a href="http://2bits.com">http://2bits.com</a><br>Drupal development, customization and consulting.