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