[development] aggregator2 update path complete!

Ashraf Amayreh mistknight at gmail.com
Mon Apr 30 13:02:15 UTC 2007


> That is the general guideline. But, of course, you're guilty of that
> as well :P SimpleFeed and others were in progress when you came along.

Was leech and simplefeed announced in the mailing list? I'm quite new to the
lists. If leech was, I'm surprised you agreed to it instead of asking the
developer to upgrade his aggregator2 module. As to simplefeed, I really
don't know too much about its history to say weather its development was
warranted or not, maybe it was, maybe not. I will say however that I'm
guilty to the core with that in lucid_menu, should have announced it first.
I'm quite over the curve where I think I'm always right, just right
99.999%of the time (i wish!) :-P

> No, hence why all the other folks are joining forces to work on seeing
> if there can be some core upgrades. If you don't want to help with
> core, that's fine.

Hey, don't get me wrong man. What I'm saying is that I need to understand
the need for an API, not that I don't want to help or anything. If the idea
is sound then you can count me in as long as I have the time for it.

I'm well aware that there was much effort spent towards this end as well as
an SoC, I'm not really in the business of undermining people's efforts. But
I can already detect some flaws here, if you simply allow overriding then
developers could override everything and you'll be left with the same amount
of code to find security issues in and so forth. Am I correct? I just don't
want us to spend so much effort in something that we may find was useless
(or worse) later on.

What I propose is to simply pick a module that would replace the core one,
create update paths from all other modules to it, and then stop all
aggregation module development. The one that should be picked is the one
most well designed. That's it. Is anyone else with me on this? We could
request that all aggregation module developers who think their modules are
candidate to step up and nominate them, then we would all get in and discuss
this until we agree on one.

> I am not sure whether you will be maintaining it or it'll be dead after a
while like the rest.

It will not, unless I happen to get infected by the RDS (Remote Death
Syndrome lol), then you'll have to pardon me :-P. Other reason is if I don't
have enough money to maintain my net connection, which in light of my
current conditions, is likely lol, but hey, what did they create
non-encrypted wireless Internet connections for? lol

> You are depending on php5. I'm still running 4 and not planning to move
now.

My use of php5 functions is limited to three locations. Using simpleXML
(search the net and you'll see that backports to php4 are available), pretty
few try catch statements, which are also replaceable, and some minimal
functions like file_put_contents and the like, they can be rewritten or (was
it PEAR?)'s compatibility layer could be used here. As a matter of fact, now
that I think about it, maybe I'll start a port to PHP 4 soon. Seems simple
enough.

Really looking forward to everyone's views on this. Had to scratch my head a
bit to come up with what I think is an alternative plan. As always, feel
free to bash at my suggestions as much as you like, that's why I'm writing
them ;-)

On 4/30/07, Mohammed Sameer <msameer at foolab.org> wrote:
>
> 2 main things are causing problems with the aggregation module:
> 1) I am not sure whether you will be maintaining it or it'll be dead
>    after a while like the rest.
> 2) You are depending on php5. I'm still running 4 and not planning to move
> now.
>
> We really have a mess and I guess the only way to solve it is a core
> aggregator rework.
> I don't have much time for that and I don't think I have much experience.
>
> What do you think ?
>
> On Mon, Apr 30, 2007 at 03:53:11AM +0300, Ashraf Amayreh wrote:
> >
> >  Post what it is you you think is lacking in the current aggregation
> modules
> >  and let's all collaborate. My aggregation module would welcome a patch
> >  anytime :-p
> >
> >  On 4/30/07, Mohammed Sameer <[1]msameer@ foolab.org> wrote:
> >
> >  [snip]
> >  On Mon, Apr 30, 2007 at 01:09:16AM +0300, Ashraf Amayreh wrote:
> >  > IMHO, we should make it compulsive 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.
> >  There's a point I want to say. Writing your own module/code is
> sometimes a
> >  lot easier
> >  than spending your time to understand the current code. I'm not sure
> what
> >  lead to having
> >  all those aggregator modules around. It even becomes worse when you
> find
> >  that most of
> >  them are either unmaintained, not working for you or your setup or not
> >  ported to the
> >  latest drupal. Then you end up writing your own.
> >  I had this problem with the stock aggregator module bringing my server
> to
> >  its
> >  knees. No time to push changes to core aggregator. The solution ? I
> have
> >  my own 100th
> >  aggregator module (Yes, I'm serious) and I'm thinking about releasing
> it
> >  since I know I'll
> >  maintain it and keep it up to date.
> >  I guess we need to work on the core one to fix it.
> >  My 0.02 Euros!
> >  --
> >  GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F 280E CB66 8E29 A3FD 0DF7
>
> >  Debian User and Developer.
> >  Homepage: [2]www.foolab.org
> >
> > References
> >
> >  1. mailto:msameer at foolab.org
> >  2. http://www.foolab.org/
>
> --
> GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F  280E CB66 8E29 A3FD 0DF7
> Debian User and Developer.
> Homepage: www.foolab.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070430/356e001e/attachment.htm 


More information about the development mailing list