In defense of the modules, Plugins actually automatically downloads the plugins, and jqp was created to automatically load plugins when dropped in a folder, rather than requiring a hook_jq info function (although jq does that now too).
But they should definitely talk together more, as there is a lot of duplicated functionality. If http://drupal.org/node/315100 gets into core, then we'll have an API, and the modules can either consolidate, vanish, or focus on functionality not included in core (such as administration screens, automatic updates, update notification, etc.)
Posted by tjholowaychuk on October 2, 2008 at 4:46pm
We have been discussing amongst each other (not the jqp author), and as aaron mentions once we can come to conclusions on which prototypes work the best then we can get rid of our other projects. Hence "this is a prototype", stop whining Greg :)
The first step is to identify the duplication. Then find any the differences. Then document them. Then people will know enough to choose the right one.
I've spent a lot of time documenting the differences in content recommendation modules for example. While I don't generally like duplication I'm wiling to live with it due to the potential benefit to the community. Part of living with it is this process of documenting the differences so that we can pick the right one.
Posted by tjholowaychuk on October 3, 2008 at 2:40pm
Good good :) I agree duplication sucks and well yeah, some of my modules take on that label, but thats how things grow into something bigger and better so like you said in the end it will be for the better. Saying that I DO think that perhaps all similar modules should link to eachothers pages, giving the average-joe a clear indication that other solutions exist and that we are simply playing out our different ideas, because I can understand frustration for these people trying to find the right module.
The first step is identifying and flagging modules which are extremely similar to each other, then looking for ways to consolidate efforts in that area. This means co-maintainership, upgrade paths, and making shared APIs to avoid duplicated code and effort.
Comments
http://drupal.org/node/315100
http://drupal.org/node/315100 should fix that ;)
In defense of the modules, Plugins actually automatically downloads the plugins, and jqp was created to automatically load plugins when dropped in a folder, rather than requiring a hook_jq info function (although jq does that now too).
But they should definitely talk together more, as there is a lot of duplicated functionality. If http://drupal.org/node/315100 gets into core, then we'll have an API, and the modules can either consolidate, vanish, or focus on functionality not included in core (such as administration screens, automatic updates, update notification, etc.)
Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
We have been discussing
We have been discussing amongst each other (not the jqp author), and as aaron mentions once we can come to conclusions on which prototypes work the best then we can get rid of our other projects. Hence "this is a prototype", stop whining Greg :)
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
not whining
The first step is to identify the duplication. Then find any the differences. Then document them. Then people will know enough to choose the right one.
I've spent a lot of time documenting the differences in content recommendation modules for example. While I don't generally like duplication I'm wiling to live with it due to the potential benefit to the community. Part of living with it is this process of documenting the differences so that we can pick the right one.
knaddison blog | Morris Animal Foundation
Good good :) I agree
Good good :) I agree duplication sucks and well yeah, some of my modules take on that label, but thats how things grow into something bigger and better so like you said in the end it will be for the better. Saying that I DO think that perhaps all similar modules should link to eachothers pages, giving the average-joe a clear indication that other solutions exist and that we are simply playing out our different ideas, because I can understand frustration for these people trying to find the right module.
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
mission statement of this group
Please note: