<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote type="cite">That brings me to the question that I'm not
getting any answer to, why
not delete aggregator2 from the repository? If there's some policy I
don't know about to NOT do that then I'd like to know about it.
</blockquote>
Agg2 is still being used and at one time was a decent module. It would
be nice for older users of Agg2 to have an easy update path and to not
add yet another aggregation module. You could completely rewrite the
code and add an aggregator2_update_X() in the .install file to wipe the
data and convert it to your module's schema like was suggested earlier.
This is what I would prefer as the list of modules is just getting too
damn big.<br>
<br>
Since people are still using Agg2, we shouldn't just delete it and
discontinuing it will force people to manually port their data to some
new module instead of having to just run update.php once.<br>
<br>
HTH,<br>
<pre class="moz-signature" cols="72">Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
<a class="moz-txt-link-freetext" href="http://www.electronicinsight.com">http://www.electronicinsight.com</a>
<a class="moz-txt-link-abbreviated" href="mailto:rob@electronicinsight.com">rob@electronicinsight.com</a></pre>
<br>
<br>
Ashraf Amayreh wrote:
<blockquote
cite="mida53d1b3b0703220010h197f17f6idd6ceba113478095@mail.gmail.com"
type="cite">>So, there was agreement on that being the route to
take, but it was not.
<br>
<br>
Because I later anticipated problems that I hadn't thought of when I
had this conversation. Weather these problems were found or not, my
knowledge in drupal wasn't "absolute" enough for me to be so sure. So I
rightfully chose the safest path as I guess anyone else would. And to
avoid calling it aggregator3 as this would, as Boris put it
<br>
<br>
> reinforces the idea in
peoples' minds that they should just rewrite from >scratch rather
than
collaborating.<br>
<br>
I chose aggregation to try my best and conform to your guidelines, so I
don't understand why you're acting as if it was an act of mischief.
That brings me to the question that I'm not getting any answer to, why
not delete aggregator2 from the repository? If there's some policy I
don't know about to NOT do that then I'd like to know about it.
<br>
<br>
<div><span class="gmail_quote">On 3/22/07, <b
class="gmail_sendername">Khalid Baheyeldin</b> <<a
href="mailto:kb@2bits.com">kb@2bits.com</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;">
<div><span class="e" id="q_1117799d7ec243f7_0"><br>
<br>
<div><span class="gmail_quote">On 3/20/07, <b
class="gmail_sendername">Ashraf Amayreh</b> <<a
href="mailto:mistknight@gmail.com" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">
mistknight@gmail.com</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;">>It
is trivial to make an update to do this and retain the schema<br>
>versions. This is exactly what the update system was designed for.<br>
<br>
>If you want to do it properly, you should keep as much existing
data
<br>
>as is reasonable.<br>
<br>
I really hope it is very clear that I did not want to worry about<br>
anything pertaining to aggregator2. It's data included. Using its own<br>
update file and building on it would be doing that.
<br>
<br>
I could however provide an option for migrating aggregator2 data to<br>
the Aggregation module, would be quite interesting really. Also, if I<br>
used the aggregation2's update file as a base, what would my next
<br>
update hook do? It would drop the aggregator2 tables and create mine.<br>
Just think of what an aggregator2 user would do if he mistakingly<br>
downloaded my module and ran the upgrade script! (yes, users do ignore<br>
regulations, I've had a number of PHP 4 users install my module
<br>
although the project page bluntly says not to). Some things are so<br>
messy they're better off left alone. If there's a remote risk that<br>
data will be lost because I'm using the aggregator2 name, why even
<br>
risk it? Which reminds me...<br>
<br>
>umm... why not just delete aggregator2 from the repository?<br>
<br>
Is there some reason why we shouldn't just do that?<br>
</blockquote>
</div>
<br>
<br clear="all">
</span></div>
Ashraf<br>
<br>
Here is the email chain from the CVS application, to jog your memory:<br>
<br>
=== Boris:<br>
<br>
What about taking over / replacing aggregator2? It's been abandoned in
any case....<br>
<br>
I think we really, really don't want something called aggregator3. The
feedparser and related modules are going in yet another direction (sort
of).
<br>
<br>
Either call it aggregator_api or take over/replace aggregator2 --
that's my vote.<br>
<br>
=== Ashraf:<br>
<br>
Replacing aggregator2 is fine with me, but this will give people the
impression that this is an upgraded aggregator2 where it is a complete
overhaul. They may also seek help for aggregator2 which I really would
rather not get into. Any downside in naming it aggregator3? Sound to me
it means the successor of aggregator2, which essentially is what it is.
<br>
<br>
=== Boris:<br>
<br>
The downside to naming it aggregator3 is that it reinforces the idea in
peoples' minds that they should just rewrite from scratch rather than
collaborating. It sounds like you've put a lot of work into your module
and really done architecting...many other are guilty of just not
bothering to try and figure out how to work together, or just slapping
some code together.
<br>
<br>
So...the downside is that the more serious of developers will not look
kindly on somethingsomething3. Yes, naming is important :P<br>
<br>
And, as a "successor" to agg2...I'd rather, as I said, just make it a
new release. We've got the new release version in place to facilitate
exactly this. We can clear out the issue queue if this is agreed to by
all. <br>
<br>
=== Ashraf:<br>
<br>
The reason I began this module was to put aggregator2 out of its misery
:-) aggregator2 is buggy (anyone who even got it to work on 4.7 knows
what I mean), it's huge (3000+ code), it's SLOW, and way too messy for
a relatively simple job.
<br>
<br>
There's no common code between this module and aggregator2, they have
radically different table schemas, this one supports images while the
older did not, this one can be extended to parse any feed while
aggregator2 was made for ATOM and RSS. This one was developed with an
eye on performance. I didn't put any effort to map old aggregator2
items to this new module. And I don't want users to get the impression
that this is an upgrade to their aggregator2 modules, which would be
the case if they found it under the same name, not something they would
be too happy about either.
<br>
<br>
If there's something I faild to catch then please let me know, but it's
my understanding that new releases need to cleanup, migrate, and make
things look relatively the same for end users. This was never taken
into consideration with this module. If the name is the only issue,
then let's just call it "generic_aggregator". Are we ok with that? <br>
<br>
=== Khalid:<br>
<br>
A while ago, there was discussion on this list on the various aggregator<br>
alternatives and extensions.<br>
<br>
It is archived here:<br>
<a
href="http://lists.drupal.org/pipermail/development/2006-October/020060.html"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.drupal.org/pipermail/development/2006-October/020060.html</a><br>
<br>
There is also this wiki page<span class="q"><br>
<a href="https://svn.bryght.com/dev/wiki/DrupalFeedParsing"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://svn.bryght.com/dev/wiki/DrupalFeedParsing
</a><br>
<br>
</span>Basically, aggregator2 has been abandoned, and leech news is
one of<br>
the successors (same author IIRC).<br>
<br>
I think that I agree with Boris for not naming something *3 for the
reasons<br>
he listed.
<br>
<br>
Since aggregator2 is abandoned, we can do this:<br>
<br>
- make you the project owner/maintainer of aggregator2.<br>
- get you CVS access.<br>
- you rewrite it, with the project page saying that 4.7.x-2.0 is a
total rewrite.
<br>
- no need for backward compatibility, and you clearly say that this is
not offered.<br>
<br>
aggregator2 performance sucks, and I spent a lot of time trying to
pinpoint the<br>
performance bottleneck on the news site, with Shadi and Tamer.
Aggregator2
<br>
was the culprit here.<br>
<br>
By the way, my first contributed Drupal module (feedback) was a total
rewrite of<br>
an existing abandoned module by the same name. Only the name was shared,<br>
and it was abandoned when I rewrote it. Later, Wolfgang Zeigler rewrote
my version,
<br>
and I grant him CVS access to the project.<br>
<br>
This is the beauty of refactoring open source software.<br>
<br>
So, go ahead and try that route.<br>
<br>
=== Ashraf:<br>
<br>
Sure, this sounds ok to me<br>
<br>
So, there was agreement on that being the route to take, but it was
not.
<br>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>