|
List Info
Thread: Re: aggregator2 update path complete!
|
|
| Re: aggregator2 update path complete! |
|
2007-04-29 23:05:05 |
|
> 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
|
| Re: aggregator2 update path complete! |
 
United States |
2007-04-29 23:32:33 |
>
> 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.
>
Not to mention, and I think this is important to add, it
would be
massively easier to extend or change out this system as
needed.
Drupal really needs a stronger API, as it will drastically
reduce the
cost of supporting the code base. And the flexibility of
common API
functions for building larger applications cannot be
underestimated.
+1 More like this please.
Jonathan Lambert
|
|
[1-2]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|