lucid menu & aggregation
Hello everyone, Just wanted to point that I had just launched the first beta release of lucid_menu, my second module, hope people can try it out and pound at it a bit :-) I'm sure many issues and bugs will spring up soon! I'd like to also welcome any suggestions regarding the aggregation module, it seems extremely solid after a month's release and most glitches have been solved. All feedback is warmly welcome! With Regards, Ashraf Amayreh
On 3/16/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
Hello everyone,
Just wanted to point that I had just launched the first beta release of lucid_menu, my second module, hope people can try it out and pound at it a bit :-) I'm sure many issues and bugs will spring up soon!
Looks interesting. You might want to link to a demo: http://www.donnaiwan.com/doiMenu/demo/index.html
I'd like to also welcome any suggestions regarding the aggregation module, it seems extremely solid after a month's release and most glitches have been solved. All feedback is warmly welcome!
Feedback: we have too many different aggregation modules and all you module authors should get together and co-maintain one or two solid modules rather than writing new ones! :P I've tried to keep a wiki page updated with an overview of all aggregation modules, but it is out of date. See https://svn.bryght.com/dev/wiki/DrupalFeedParsing and feel free to add Aggregation and edit as needed. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Boris Mann a ecrit le 19/03/2007 15:45:
On 3/16/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
I'd like to also welcome any suggestions regarding the aggregation module, it seems extremely solid after a month's release and most glitches have been solved. All feedback is warmly welcome!
Feedback: we have too many different aggregation modules and all you module authors should get together and co-maintain one or two solid modules rather than writing new ones! :P
+1 - some consolidation would be awesome !!
Feedback: we have too many different aggregation modules and all you module authors should get together and co-maintain one or two solid modules rather than writing new ones! :P
+1 - some consolidation would be awesome !!
As long as similar modules contain unique features, I don't think there's much of a problem, this simply provides variance to choose from to suite your specific needs. Oh, ATOM 1.0 support just added!!! Make sure to try it out :-)
On Monday 19 March 2007 7:46 pm, Ashraf Amayreh wrote:
Feedback: we have too many different aggregation modules and all you module authors should get together and co-maintain one or two solid modules rather than writing new ones! :P
+1 - some consolidation would be awesome !!
As long as similar modules contain unique features, I don't think there's much of a problem, this simply provides variance to choose from to suite your specific needs. Oh, ATOM 1.0 support just added!!! Make sure to try it out :-)
Given the choice between 5 modules that each do a third of the full feature set or one module that does it all, I'd much rather have the one module and not have to deal with the question of "which of these is closest to what I need even though none of them do both A and F, which is the combination I need?" Consolidation++. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Ashraf Amayreh a ecrit le 20/03/2007 01:46:
As long as similar modules contain unique features, I don't think there's much of a problem,
Wrong, this is exactly the problem. I just spend two days evaluating the 5 or 6 different 'aggregator enhanced' modules out there, and finally picked one, founding none of them completely satisfying, while most of them having really great bits. Quite frustrating. Competition can have its merits , but the time and efforts of developpers and of the community at large (debugging, reviewing, patch submitting...) are generally best put into enriching / strengthening an existing module when possible instead of being spilled over 5 or six different contribs.
As long as similar modules contain unique features, I don't think there's much of a problem,
Wrong, this is exactly the problem. I just spend two days evaluating the 5 or 6 different 'aggregator enhanced' modules out there, and finally picked one, founding none of them completely satisfying, while most of them having really great bits. Quite frustrating.
Maybe you aught to submit an issue with your suggestions to the "closest" module? Many enhancements I made were based on such submissions. I'd hate to say this, but some contributed modules are so badly written, so badly documented, that patching them up would be a living nightmare (trust me, I WAS there). Sometimes the best way to produce something excellent is to simply not base it on something severely flawed (I'm not mentioning any modules here! Some aggregation modules were launched parallel or even after mine I hadn't even tried them, so I'm not even implying any module here! Some modules are simply so spectacular it's silly to go about inventing the wheel again.) Some had the logic thrown right into them in a pretty ugly way. I attempted to create a module that's extremely clean, extensible and efficient. So it's a software engineering standpoint that made it the right decision.
but the time and efforts of developpers and of the community at large (debugging, reviewing, patch submitting...) are generally best put into enriching / >strengthening an existing module when possible instead of being spilled over 5 or >six different contribs.
Better that than wasting developer and community time searching for bugs in spaghetti code :-) I'm sure no one would say that creating drupal should have gone into enhancing another CMS ;-)
Ashraf Amayreh a ecrit le 20/03/2007 09:43:
Maybe you aught to submit an issue with your suggestions to the "closest" module? Many enhancements I made were based on such submissions.
I sometimes cross post features request to similar modules suggesting mainainers to merge their efforts. And yes, that's my point, submitting patches / features requests to existing modules should be the first step before rolling your own module.
I'd hate to say this, but some contributed modules are so badly written, so badly documented, that patching them up would be a living nightmare
Quite true, obviously :-).
Some had the logic thrown right into them in a pretty ugly way. I attempted to create a module that's extremely clean, extensible and efficient. So it's a software engineering standpoint that made it the right decision.
Now, _that_ is a good reason to consider forking or rolling a new module. The 'new and exclusive features' argument, whiich I was reacting to, is not, IMO. There are too many modules in contrib. Consolidation is not always possible or appropriate, but should be considered first.
Ashraf I recall when you were applying for CVS access that we recommended that you take over aggregator2 and then commit your code to it, making it a total rewrite of an abandoned module. If this was done, then we would have one less module in this whole confusing area of aggregators. Overlapping or duplication of functionality without a good reason is not good. On a related note, the best way forward on aggregators is to make them componentized using a defined API. Then people can write plugins to the API, or pick and choose from what is available.
I recall when you were applying for CVS access that we recommended that you take over aggregator2 and then commit your code to it, making it a total rewrite of an abandoned module.
umm... why not just delete aggregator2 from the repository?
If this was done, then we would have one less module in this whole confusing area of aggregators.
I didn't use aggregator2 for a number of reasons, from critical to trivial : 1. When disabling a module in 4.7, the database retains that the module was installed to prevent the module's re-installation and to which update hook it ran AFAIK. This would effectively mean that any previous aggregator2 users wouldn't even be able to install the new aggregator2 module (install script wouldn't run!), and that my own update hooks would clash with the old aggregator2's update hooks! Not something I wanted to get myself into! 2. I named the tables <module_name>_item and <module_name>_feed. if I took over aggregator2 that would have meant their names would be exactly like those of aggregator2's table names, and then I'd have a new headache of either changing table names for the sole reason of coping with aggregator2, or risk duplicate table names, just something I didn't want to get myself into. 3. Didn't want to associate the new module implementation with the many forum topics on aggregator2. 4. I didn't want to create a mix up for old aggregator2 users.
On a related note, the best way forward on aggregators is to make them componentized using a defined API. Then people can write plugins to the API, or pick and choose from what is available.
My module does contain a developer's API. It's relatively trivial to add aggregation for any XML format, standard or not.
1. When disabling a module in 4.7, the database retains that the module was installed to prevent the module's re-installation and to which update hook it ran AFAIK. This would effectively mean that any previous aggregator2 users wouldn't even be able to install the new aggregator2 module (install script wouldn't run!), and that my own update hooks would clash with the old aggregator2's update hooks! Not something I wanted to get myself into!
It is trivial to make an update to do this and retain the schema versions. This is exactly what the update system was designed for. If you want to do it properly, you should keep as much existing data as is reasonable. Steven Wittens
Agg2 was a giant ball of hairy code that no one wanted to touch, including the original developer. ANYWAY, my point here was that there clearly too many aggregation / feedparsing modules, and there is no way that they're all going to be maintained or of high quality. Joining forces seems to be the natural thing to do, but hey, what do I know? I'm just a handwaver.... Again, if anyone feels like helping compare, feel free to update -- https://svn.bryght.com/dev/wiki/DrupalFeedParsing My current vote is for Ted Serbinski's SimpleFeed module. I *also* bitched at him about starting fresh, but he had a clear path, had spoken with other module authors, and, well, has a good history. if you really want to make friends, refactoring + extending of the core Aggregator module in the form of patches for D6 would be great. Hmm....that would be another good SoC, probably. -- Boris Mann Skype borismann http://www.bryght.com
It is trivial to make an update to do this and retain the schema versions. This is exactly what the update system was designed for.
If you want to do it properly, you should keep as much existing data as is reasonable.
I really hope it is very clear that I did not want to worry about anything pertaining to aggregator2. It's data included. Using its own update file and building on it would be doing that. I could however provide an option for migrating aggregator2 data to the Aggregation module, would be quite interesting really. Also, if I used the aggregation2's update file as a base, what would my next update hook do? It would drop the aggregator2 tables and create mine. Just think of what an aggregator2 user would do if he mistakingly downloaded my module and ran the upgrade script! (yes, users do ignore regulations, I've had a number of PHP 4 users install my module although the project page bluntly says not to). Some things are so messy they're better off left alone. If there's a remote risk that data will be lost because I'm using the aggregator2 name, why even risk it? Which reminds me...
umm... why not just delete aggregator2 from the repository?
Is there some reason why we shouldn't just do that?
Ashraf Amayreh wrote:
It is trivial to make an update to do this and retain the schema versions. This is exactly what the update system was designed for.
If you want to do it properly, you should keep as much existing data as is reasonable.
I really hope it is very clear that I did not want to worry about anything pertaining to aggregator2. It's data included. Using its own update file and building on it would be doing that.
I could however provide an option for migrating aggregator2 data to the Aggregation module, would be quite interesting really. Also, if I used the aggregation2's update file as a base, what would my next update hook do? It would drop the aggregator2 tables and create mine. Just think of what an aggregator2 user would do if he mistakingly downloaded my module and ran the upgrade script! (yes, users do ignore regulations, I've had a number of PHP 4 users install my module although the project page bluntly says not to). Some things are so messy they're better off left alone. If there's a remote risk that data will be lost because I'm using the aggregator2 name, why even risk it? Which reminds me...
People downloading a new release of aggeragtor2 will expect that it messes with their aggregator2 data. They are instructed to take backups on updates. Gabor
On 3/20/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
It is trivial to make an update to do this and retain the schema versions. This is exactly what the update system was designed for.
If you want to do it properly, you should keep as much existing data as is reasonable.
I really hope it is very clear that I did not want to worry about anything pertaining to aggregator2. It's data included. Using its own update file and building on it would be doing that.
I could however provide an option for migrating aggregator2 data to the Aggregation module, would be quite interesting really. Also, if I used the aggregation2's update file as a base, what would my next update hook do? It would drop the aggregator2 tables and create mine. Just think of what an aggregator2 user would do if he mistakingly downloaded my module and ran the upgrade script! (yes, users do ignore regulations, I've had a number of PHP 4 users install my module although the project page bluntly says not to). Some things are so messy they're better off left alone. If there's a remote risk that data will be lost because I'm using the aggregator2 name, why even risk it? Which reminds me...
umm... why not just delete aggregator2 from the repository?
Is there some reason why we shouldn't just do that?
Ashraf Here is the email chain from the CVS application, to jog your memory: === Boris: What about taking over / replacing aggregator2? It's been abandoned in any case.... I think we really, really don't want something called aggregator3. The feedparser and related modules are going in yet another direction (sort of). Either call it aggregator_api or take over/replace aggregator2 -- that's my vote. === Ashraf: 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. === Boris: 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. So...the downside is that the more serious of developers will not look kindly on somethingsomething3. Yes, naming is important :P 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. === Ashraf: 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. 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. 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? === Khalid: A while ago, there was discussion on this list on the various aggregator alternatives and extensions. It is archived here: http://lists.drupal.org/pipermail/development/2006-October/020060.html There is also this wiki page https://svn.bryght.com/dev/wiki/DrupalFeedParsing Basically, aggregator2 has been abandoned, and leech news is one of the successors (same author IIRC). I think that I agree with Boris for not naming something *3 for the reasons he listed. Since aggregator2 is abandoned, we can do this: - make you the project owner/maintainer of aggregator2. - get you CVS access. - you rewrite it, with the project page saying that 4.7.x-2.0 is a total rewrite. - no need for backward compatibility, and you clearly say that this is not offered. aggregator2 performance sucks, and I spent a lot of time trying to pinpoint the performance bottleneck on the news site, with Shadi and Tamer. Aggregator2 was the culprit here. By the way, my first contributed Drupal module (feedback) was a total rewrite of an existing abandoned module by the same name. Only the name was shared, and it was abandoned when I rewrote it. Later, Wolfgang Zeigler rewrote my version, and I grant him CVS access to the project. This is the beauty of refactoring open source software. So, go ahead and try that route. === Ashraf: Sure, this sounds ok to me So, there was agreement on that being the route to take, but it was not.
So, there was agreement on that being the route to take, but it was not.
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
reinforces the idea in peoples' minds that they should just rewrite from scratch rather than collaborating.
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. On 3/22/07, Khalid Baheyeldin <kb@2bits.com> wrote:
On 3/20/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
It is trivial to make an update to do this and retain the schema versions. This is exactly what the update system was designed for.
If you want to do it properly, you should keep as much existing data as is reasonable.
I really hope it is very clear that I did not want to worry about anything pertaining to aggregator2. It's data included. Using its own update file and building on it would be doing that.
I could however provide an option for migrating aggregator2 data to the Aggregation module, would be quite interesting really. Also, if I used the aggregation2's update file as a base, what would my next update hook do? It would drop the aggregator2 tables and create mine. Just think of what an aggregator2 user would do if he mistakingly downloaded my module and ran the upgrade script! (yes, users do ignore regulations, I've had a number of PHP 4 users install my module although the project page bluntly says not to). Some things are so messy they're better off left alone. If there's a remote risk that data will be lost because I'm using the aggregator2 name, why even risk it? Which reminds me...
umm... why not just delete aggregator2 from the repository?
Is there some reason why we shouldn't just do that?
Ashraf
Here is the email chain from the CVS application, to jog your memory:
=== Boris:
What about taking over / replacing aggregator2? It's been abandoned in any case....
I think we really, really don't want something called aggregator3. The feedparser and related modules are going in yet another direction (sort of).
Either call it aggregator_api or take over/replace aggregator2 -- that's my vote.
=== Ashraf:
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.
=== Boris:
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.
So...the downside is that the more serious of developers will not look kindly on somethingsomething3. Yes, naming is important :P
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.
=== Ashraf:
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.
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.
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?
=== Khalid:
A while ago, there was discussion on this list on the various aggregator alternatives and extensions.
It is archived here: http://lists.drupal.org/pipermail/development/2006-October/020060.html
There is also this wiki page https://svn.bryght.com/dev/wiki/DrupalFeedParsing
Basically, aggregator2 has been abandoned, and leech news is one of the successors (same author IIRC).
I think that I agree with Boris for not naming something *3 for the reasons he listed.
Since aggregator2 is abandoned, we can do this:
- make you the project owner/maintainer of aggregator2. - get you CVS access. - you rewrite it, with the project page saying that 4.7.x-2.0 is a total rewrite. - no need for backward compatibility, and you clearly say that this is not offered.
aggregator2 performance sucks, and I spent a lot of time trying to pinpoint the performance bottleneck on the news site, with Shadi and Tamer. Aggregator2
was the culprit here.
By the way, my first contributed Drupal module (feedback) was a total rewrite of an existing abandoned module by the same name. Only the name was shared, and it was abandoned when I rewrote it. Later, Wolfgang Zeigler rewrote my version, and I grant him CVS access to the project.
This is the beauty of refactoring open source software.
So, go ahead and try that route.
=== Ashraf:
Sure, this sounds ok to me
So, there was agreement on that being the route to take, but it was not.
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. 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.
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. HTH, Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Ashraf Amayreh wrote:
So, there was agreement on that being the route to take, but it was not.
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
reinforces the idea in peoples' minds that they should just rewrite from >scratch rather than collaborating.
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.
On 3/22/07, *Khalid Baheyeldin* <kb@2bits.com <mailto:kb@2bits.com>> wrote:
On 3/20/07, *Ashraf Amayreh* < mistknight@gmail.com <mailto:mistknight@gmail.com>> wrote:
>It is trivial to make an update to do this and retain the schema >versions. This is exactly what the update system was designed for.
>If you want to do it properly, you should keep as much existing data >as is reasonable.
I really hope it is very clear that I did not want to worry about anything pertaining to aggregator2. It's data included. Using its own update file and building on it would be doing that.
I could however provide an option for migrating aggregator2 data to the Aggregation module, would be quite interesting really. Also, if I used the aggregation2's update file as a base, what would my next update hook do? It would drop the aggregator2 tables and create mine. Just think of what an aggregator2 user would do if he mistakingly downloaded my module and ran the upgrade script! (yes, users do ignore regulations, I've had a number of PHP 4 users install my module although the project page bluntly says not to). Some things are so messy they're better off left alone. If there's a remote risk that data will be lost because I'm using the aggregator2 name, why even risk it? Which reminds me...
>umm... why not just delete aggregator2 from the repository?
Is there some reason why we shouldn't just do that?
Ashraf
Here is the email chain from the CVS application, to jog your memory:
=== Boris:
What about taking over / replacing aggregator2? It's been abandoned in any case....
I think we really, really don't want something called aggregator3. The feedparser and related modules are going in yet another direction (sort of).
Either call it aggregator_api or take over/replace aggregator2 -- that's my vote.
=== Ashraf:
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.
=== Boris:
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.
So...the downside is that the more serious of developers will not look kindly on somethingsomething3. Yes, naming is important :P
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.
=== Ashraf:
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.
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.
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?
=== Khalid:
A while ago, there was discussion on this list on the various aggregator alternatives and extensions.
It is archived here: http://lists.drupal.org/pipermail/development/2006-October/020060.html
There is also this wiki page https://svn.bryght.com/dev/wiki/DrupalFeedParsing <https://svn.bryght.com/dev/wiki/DrupalFeedParsing>
Basically, aggregator2 has been abandoned, and leech news is one of the successors (same author IIRC).
I think that I agree with Boris for not naming something *3 for the reasons he listed.
Since aggregator2 is abandoned, we can do this:
- make you the project owner/maintainer of aggregator2. - get you CVS access. - you rewrite it, with the project page saying that 4.7.x-2.0 is a total rewrite. - no need for backward compatibility, and you clearly say that this is not offered.
aggregator2 performance sucks, and I spent a lot of time trying to pinpoint the performance bottleneck on the news site, with Shadi and Tamer. Aggregator2 was the culprit here.
By the way, my first contributed Drupal module (feedback) was a total rewrite of an existing abandoned module by the same name. Only the name was shared, and it was abandoned when I rewrote it. Later, Wolfgang Zeigler rewrote my version, and I grant him CVS access to the project.
This is the beauty of refactoring open source software.
So, go ahead and try that route.
=== Ashraf:
Sure, this sounds ok to me
So, there was agreement on that being the route to take, but it was not.
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.
The original suggestion that I take over aggregator2 was not for the purpose of providing an upgrade route for aggregator2 users. If this was the reason given, I would have handled it very differently. I don't want people to think this is what was suggested and what I avoided. Even if I chose to take over aggregator2 before, aggregator2 users would have been left pretty high and dry. I believe your argument is the most convincing so far. Aggregator2 users need a good upgrade route. The best I can do is provide an upgrade_X hook in the aggregator2 module that would transfer its data to my schema, then users could disable aggregator2 altogether and run mine which would take over, that is, if they can meet my module's requirements (PHP5, CURL) and accept its current features. This was not on my agenda, but it's the right thing to do. If someone can think of a better alternative to ease this process, then please let me know. Khaled, can we transfer the aggregator2 project, its issues and cvs files to my user "mistknight"?
On 3/22/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
Khaled, can we transfer the aggregator2 project, its issues and cvs files to my user "mistknight"?
OK, you are know the owner of this project, and hence have cvs access to it. My personal position is that if you provide an upgrade path, it would be nice and a good service to the users. It is not required though given that it is formally abandoned (for leech module by the same user). Put a notice on the project that this module is not to be used, will be killed soon, upgrade path, ...etc. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
participants (8)
-
Ashraf Amayreh -
Boris Mann -
Gabor Hojtsy -
Khalid Baheyeldin -
Larry Garfield -
Rob Barreca -
Steven Wittens -
Yves Chedemois