Hi All--
Based on some ideas and requests generated during the Mail, Notifications & Messaging Framework session at Drupalcon Boston I decided to attempt a quick-and-simple plugin module for messaging which would make Allie Micka's most excellent MimeMail functionality available as delivery method for the Notifications & Messaging frameworks.
It was amazingly simple (two functions) thanks both to Allie's well designed mimemail() function and the design of José Reyero's Messaging framework.
It's now in the Messaging framework's CVS:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/messaging/m...
Please take a look and let me know what you'd like to see added. I know that I will likely be adding a mime_mail_message_render() function to add some html niceties to outgoing emails. What else is needed?
Comments
Thats what I'm talking
Thats what I'm talking about! Great to see this happen coming so soon after the session. Yea for momentum.
Ideally to be really well integrated with the Send API
http://drupal.org/project/send
http://drupal.org/project/mimemail
http://drupal.org/project/mlm
benjamin, Agaric Design Collective
benjamin, agaric
I'm slightly confused
Benjamin--
The module I added merely allows notifications generated by the Notifications module/framework to be delivered by Allie's Mimemail module. From what I can tell (and please anyone correct me here if I'm mistaken) Send and MLM both do their work in a space parallel to Notifications, i.e. recipient management and message event creation. in other words, they live above Messaging and it's plugins.
The only way I could imagine integrating MLM and Send with messaging would be to enable them to route their output to the messaging module and it's plugins. This would allow the users/administrators to choose the delivery methods they prefer. To the degree that it allows users to bypass the mime-ey goodness of Mimemail, it might defeat the original purpose of Send, which (again correct me if I'm wrong) was to enable sending of nicely formatted drupal nodes.
I do see how allowing users on sites with MLM to choose their delivery method could be useful. Is that something you'd be interested in seeing? Is there any other specific use case you could imagine here? Let me know--were interested in making this as useful and plung-and-play as possible.
Best,
tim
Duplication everywhere!
I tend to agree with Tim. These efforts are slightly parallel, so seeking more integration is useful, but I think that the biggest bang for your buck is in getting other modules to work better with one or both of these frameworks.
Send is actually a framework for sending and tracking various types of nodes through various delivery models. In that regard, it's a UI-centric approach to one form of notifications. There is also ( an albeit underdeveloped ) approach to tracking nodes sent out for other purposes ( e.g. through a newsletter mailing, or by subscribing to an RSS feed via Watch ). The primary intention of all of this is to determine which content types are being delivered to users, and comparing/contrasting the efficacy therein.
Given that Send was basically marketed as "an alternative to Forward", I can't possibly blame anyone for duplicating some of its goals. However, Send may occupy some interesting space that's not part of the Messaging/Notifications model. Specifically, the focus on delivery of nodes and the tracking therein, could possibly work in concert with M/N by a) having send - or a send submodule - use the messaging framework for delivery rather than using mimemail directly; or b) having something in M/N land use the Send API to track node delivery. That way, Send could incorporate M/N activity into its records.
MLM is a little fuzzy also. That module simply wants to provide a consistent UI for subscribing to various mailing lists. These lists can be internal to Drupal, or external ( such as ezmlm or a 3rd-party hosted service ). Perhaps this can provide a delivery backend to Notifications, or perhaps these should remain separate. I'm open to ideas.
Meanwhile, my biggest frustration with the fact that there are 84 - no, make that 86 - modules in the mail category is that short-term-thinking leads to duplication of effort. I think this is less of a problem with competion/cooperation of various "frameworks", and more of a problem where people aren't thinking through the component parts of their mailing goal.
For example, dozens of these 86 modules focus on (un)subscribing - or deriving subscription information ( user roles, group membership, etc. ) for a single use case. One mailing list manager, one 3rd-party service, one form of user classification ( e.g. "role" ). The end result of all of these processes is a destination for a message. However, rather than making a list available to MLM, Notifications, or some other framework; each of these modules attempts to create a parallel UI, preference settings, subscriptions workflow, and message composition/themeing. To me, that's like buying a whole new car for each of your destinations. For a site with any complexity, this can destroy all clarity for basic tasks such as changing subscription or format preferences throughout the site.
If we could get some of these modules to join forces - for example, by implementing MLM backends or M/N targets, we'd have a much calmer place to start from.
+1 to the calmer place. i
+1 to the calmer place. i have read a lot of this mail code at one time or another and i am putting my effort into the Notifications/Messaging frameworks that development seed has built. i hope others do the same and we can coalesce around it as a solution.