[development] aggregator2 update path complete!

[Ken Rickard]

> IMHO, we should make it [compulsory] that every module developer post to
the
> mailing list before setting on a new module. This may prevent the
> catastrophe of so much repeated modules and repeated code.

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.

That aside, the Aggregator API addresses two fundamental problems:

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.

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.

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.

> 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?

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.

>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.)

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.

The proposed work is moving towards fixing core Aggregator because that's
where the best, most stable benefit is for the largest user base.

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....

- Ken Rickard
agentrickard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070430/0a376047/attachment.htm