[development] D7 contrib module development

[Matt Chapman]

Marcel Partap wrote:
> So the solution would be two frameworks:
> "Hi, i am the messaging framework and responsible for handling all
> communication. You can enable different sub modules for mail, sms,
> jabber, twitter, smoke signaling according to your needs." and
> "This module is for handling change notifications of nodes, fields and
> comments. By itself it does not expose any UI."
> plus the correspondent modules building on that:
> "regular notifications UI - user interface to enable intervalled
> updates for all types of subscriptions"
> "change notifications UI - notify users when an Drupal object changes"
> "advanced subscription settings UI - provide UI for more precise
> control of content subscriptions"
> (something along these lines, i'm sure many people more experienced
> with this stuff than me can do better)

So now the first time site builder who just wants his friends to be able 
to decide if they want to receive email notice of new content needs to 
download and enable the right combination of at least 3 modules. Or he 
can just download and enable notify module.

As a developer, sometimes it much easier for me to write my own solution 
to my own simple problem than to take the time to learn someone else's 
framework for a generic class of similar problems. Sometimes, 
duplicating basic code is the more efficient  process, especially in a 
system as complex as you describe.

Also, the cost of change is factor in the real world. Even though notify 
module is an inferior module on several levels, it was easier to upgrade 
it to D6 than to switch to one of the newer frameworks. Probably the 
only reason notify module still exists is because it's the oldest of the 
solutions. If someone wants to write a migration tool for the 
notifications or subscriptions framework, and a UI module that 
duplicates notify's simplicity, once these are included in the framework 
download package, I will gladly shutdown notify.


Best,

Matt