John<br><br>There is no "offense", "food chain", nor "by the book crowd". 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 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> <
<a href="mailto:john@nashvillesnews.net">john@nashvillesnews.net</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;">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'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't think is needed at all (I'm open to other opinions though if they'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't just throw away his work, create an alternative module, and
<br><br><br>leave things behind as if they'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'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. Ashraf is exactly right here.<br><br> I sponsored the development of Aggregator2 for a reason. The purpose was to create a publishing platform that could consume and display RSS content and had nothing to do with an API. I full well understand the difference so please save your lectures for someone else. None of the modules other than Ashraf's Aggregation module come close to providing the Aggregator2 intended functionality for
4.7x or 5.xx. <br><br>He's done the exact right thing here. I'm sort of curious what the actual offense to the development process is supposed to be. I guess I'm missing the issue totally as it seems to be that he added to the confusion by creating another option.
<br><br>So what? <br><br>I suppose its a matter of your place in the food chain. His Aggregation module works and incorporates the best aspects of Aggregator2 and extends it in ways that are excellent. Api work has little to now end user or immediate application for working sites. It is a different concern.
<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'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 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. The testing and knowledge gained from putting it to use has been invaluable.
<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.