[development] aggregator2 update path complete!

Khalid Baheyeldin kb at 2bits.com
Tue May 1 02:49:18 UTC 2007


There is no "offense", "food chain", nor "by the book crowd". Your choice of
here does not reflect reality.

A bit of history here:

Agg2 was used by some site that Ashraf worked on, and the ugliness was
evident. Performance sucked big time.

So, Ashraf proposed an aggregator3, which is a successor of aggregation2.
The list here, rightfully so, objected to module2, module3, ...etc, and
Ashraf to take over agg2 and rewrite it if necessary.

However, for reasons that Ashraf stated before (convincing for some, not for
others) he named his module aggregation.

Back to APIs. As you said an end user cares less if there is an API or not,
or if
the code is elegant or not, as long as it does the job. However, Drupal is
ecosystem, not just a CMS. If an API for something evolves, it will get
refined, refactored and everyone wins. Look at FormAPI for example, and
Drupal since 4.7 is. It is amazing.

An example from my own set of modules: I am the author of one of the first
voting modules for Drupal (nodevote). It did the job and many people use it.

Then Jeff Eaton came along and wrote the Voting API which is used for Vote
Up/Down, Fivestar, Simple vote, custom vote and  Medium Vote.

I could have been overprotective and refuse to do it because of a NIH
(not invented here). On the contrary, I know a good idea when I see it, and
have been contemplating moving nodevote to Voting API for a year now, but
time does not permit it. There is some renewed interest in this, and it will

probably get done.

Conversely, Userpoints is a module that evolved from an application to an
API and is now used by many others modules (released and unreleased).

APIs make things easier for everyone, and it is good that people pool
rather than cling to their own piece of code and be overprotective about it.

I now step down from the soap box.

On 4/30/07, John Bransford <john at nashvillesnews.net> wrote:
> Ashraff wrote this
> 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 wanted to put in my two cents.  Ashraf is exactly right here.
>  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.
> 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.
> So what?
> 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.
> 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.
> 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.
> 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.
> Thanks Ashraf
> --
> Binserver
> http://Binserver.com
> http://NashvillesNews.net
> (615) 349-8841

Drupal development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070430/d8ee0b07/attachment.htm 

More information about the development mailing list