Subscriptions vs. Notifications vs. Project issue's mail.inc
Here are some notes that I took while comparing these system, based on a couple hours of poking around and reading code. Anyone feel free to jump in here and correct me on any of this stuff, especially if you've actually /used/ either of these modules before. :P
Subscriptions module came first. This module has been around a long time (since at least 4.3), and gone through many different maintainers. In Drupal 5, chx re-wrote large parts of it to make a 5.x-2.x branch, and the current maintainer, salvis, seems to be very involved and keen. However, due simply to the age of the module, some of the code is a bit convoluted.
Notifications module is a fork of Subscriptions by the Development Seed guys that has some code clean-up and has made the code more modular. So modular, in fact, that one could argue it's been taken to completely insane levels. ;) But it has some nice features like Mailhandler integration (which is also in mail.inc, although I doubt that anyone's used it since it was coded :P), the ability to send notifications via SMS, etc.
Each module employs a "stack" something like the following:
- Basic API functions for managing subscriptions and the queues of what stuff to send to whom: Subscriptions/Notifications modules, which are configured with Subscriptions UI/Notifications UI modules.
- The "Send the notifications out" part. Subscriptions uses the bundled Subscriptions Mail module, Notifications piggy-backs off the Messaging module to provide this. Messaging, in turn, provides sub-modules to send things via e-mail (PHPMailer or regular drupal_mail()), SMS, etc.
- The "What stuff can you subscribe to?" part. Both modules provide a hook that other modules can implement in order to provide subscription forms. So you have sub-modules like subscriptions/notifcations_taxonomy.module, subscriptions/notifications_content.module, subscriptions/notifications_cck.module, etc., each of which explain how those modules innards work to the appropriate module.
What this means in the practical sense is that whichever solution we go with is going to mean module dependency fever: we need at least 5 sub-modules with Subscriptions module (though html_to_text is included in D6), and something like 9-10 with Notifications/Messaging, in order to get the same functionality as our lovely little mail.inc. Furthermore, we wouldn't be eliminating any code, really. We'd simply be moving most of our logic from mail.inc to project_issue_subscriptions/notifications.module. :\
What I would love to see instead is for someone to write a views_subscribe.module (or whatever) that handles the "list of stuff" that should be subscribed to. This would then integrate with either Subscriptions or Notifications module to handle the queueing/actually send mail/SMS/whatever to people stuff. chx has some notes written about this here: http://drupal4hu.com/node/57
Rationale: Project issue already has Views integration (aclight tells me that Views required in D6). So does Organic Groups, taxonomy, CCK, etc. We install something on Drupal.org like Flag module, which allows people to toggle a "subscribe" flag on project issues (or, heck, anything! forum topics, etc). Then the "My issues" view is adjusted to look for those, and views_subscribe is configured to send out notifications of new/updated nodes within that View by whatever means the user choosesn (RSS, SMS, E-mail, carrier pigeon...)
Thoughts?
Note that the use of a more
Note that the use of a more generic notifications system could then let people subscribe to forum posts and other important pieces that aren't just the project issue queue.
More thoughts from merlinofchaos...
Talking about a mythical views_subscribe.module:
[16:16] Ahh, nuts. I thought he'd gotten somebody to code it. :/
[16:17] And I'm not entirely sure that's quite the right way to do a subscribe-to-view module.
[16:18] Though maybe. It's kind of complicated, because subscriptions work in a different timescale than views.
[16:18] *** djohnson (n=djohnson@c-24-99-196-167.hsd1.ga.comcast.net) joined
[16:18] Hmm. Unless!
[16:19] Unless you have a 'last notified nid' table, which is nid + viewname + timestamp, and your view subscribe automatically adds that filter, comparing it to a 'last notified view' table which is just view + timestamp. Possibly with a subscription id.
[16:19] In fact maybe you use the subscription id and not the viewname.
[16:20] Then, the view automatically brings up results that have not been notified. However, you often need to be notified of changes.
[16:20] Hm.
[16:20] Complex.
[16:21] Though actually, 'nid' is dumb unless you're using views 1. If we're talking views 2, nid is wrong, because it could be multiple kinds of objects.
[16:22] And if you're pretty much hardwired to created/updated times, then that's okay too.
something
http://drupal.org/project/notify_by_views
edit: just realised this is for notify module (which is deprecated), not notifications :(
Glad you asked :) I have
Glad you asked :)
I have already placed my bet on Notifications.. OG for D5 is shipping with some nice integration. D6 will not have any native OG notification but instead leverage Notifications if present. I think Notifications is really tight. I'd like to see it used here. It started as a fork of subscriptions but it has drifted far enough that this isn't really important/relevant anymore.
You are right about Notifications requiring many modules - more than d.o is generally comfortable with. Thats further reason IMO to split off project to its own site so the project module and ratings/reviews/whatever and notifications and all that can flourish. I think Catch eloquently made the case over here.
As for Flag module - it is a plausible solution here. I think the missing link you describe can be serviced by Views Scheduler. I never used that module, so I'm not positive.
.
I've gone back and forth on these two modules. I finally settled on subscriptions but it was almost a coin toss. And now Moshe has me thinking I should have gone with notifications since I use OG on that site. I really hate that so much parallel development is going on with these two modules.
I think what gives noti the edge in this case is the ability to send the notifications to a variety of places. I know a lot of people like email when something they subscribe to is updated but I live in my tracker. I want something to show up there when a watched post is updated. I'm hoping that will eventually be possible.
Whichever one is chosen, could some jquery/js expert please do something about the UI? It sucks in both of the modules.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Flexibility is Key in the long run
I'm betting on Notifications because I see a future in sending updates to IM, Twitter, Jabber and lots of other yet to be announced web services. There seems little doubt in my mind that email is going the way of the dodo long-term, in the mean time, Notifications sets the opportunity to send to anything given a bit more development of the glue or that particular service. Someone could probably figure out some crazy way to mash these notifications into a google map for some unknown reason.
Anyway, flexibility seems like it will always win out in the long run and is one of the reasons I'm so enthusiastic about Drupal as a whole.
I'm going with Flag module.
I'm going with Flag module. I encourage you to take a look at it and review.
http://drupal.org/node/34496#comment-930005
Formatting of content
This is coming from a different angle as I am a non-developer. Possibly this comment should go somewhere else - sorry if this is an inappropriate place. Also I have only looked at Subscriptions and Notifications (and Notify, which I use at the moment and am trying to replace). Apologies to the module developers if I have mis-represented anything - I will of course correct it.
Firstly on the general question about what is a desirable degree of modularity I would say that this is a point in favour of both of Subsciptions and Notifications. It's worth looking at it the other way round, isn't it? - not that you have to have all these modules to get it to work but that actually you don't have to have them all - you only have to have the ones you really need. More than one or two, but not all of them. You don't have to load up code you are not going to use. By implication, the modules are geared towards extensibiity which is surely a good thing not a bad thing.
From that point of view, Notifications is probably better than Subscriptions because it takes that philosophy further eg with features like the messaging framework and Tokens.
With Notifications, I was able to use the mimemail message-type so my nodes came through with italics and bold etc etc preserved from the original post. And I could embed a bit of html in the template and it got translated.
I was surprised with Subscriptions (given the fact that it is such a well-developed, well-thought-out framework overall) to find that it was only going to deliver plain-text emails - following in the footsteps of the current Notify module. And looking in the support forum I noted Salvis saying "I think that trying to send out HTML emails would be
a) difficult to implement correctly and satisfactorily
b) a constant source of feature requests for additional tweaking possibilities
c) a constant source of support requests of the type "why don't my emails look like I want them to?"
The problem with that is that for my site and I am sure many others - including Drupal Groups at a guess - emails from a site are the main form of interaction with it (if getting an email can be described as interaction). Thus the appearance of those emails is particularly important. It is paradoxical if so much attention is devoted to the appearnce of websites but not the emails they send out.
Despite this drawback of Subscriptions, it was also clear from Salivs's post that an html feature would be possible through creating another add-on module. That looks like the way to go - though I wondered if an existing module might do the trick?
Where Subscriptions wins is that it works more effectively out of the tin, with lots of well-thought-out user interface options. In particular, with mail template module installed there is the list of all the different content types each with its own template. Admittedly, actually editing a template is a bit beyond me but at least I could do it if I wanted to.
In this area it was Notifications that seemed relatively deficient. Although you can select notifications by content type it didn't seem to have different templates for the different content types. The Tokens all worked very well, but there only seemed to be one template to put them into. Consequently, if you put a token from one type of cck content (lets call it type [1]) into the template and were notifiying the user of different type [2] you would get the unresolved token from [1].
As a general aside, It's hard for me as a non-tech type to understand why, given that drupal handles putting content etc onto the screen so effortlessly, it should be hard to do the same thing into an email. As far as the website goes, you can put posts of all different types onto the frontpage of your site without having to specify templates and they will all come out appropriately formatted.
Perhaps you could get around this issue with Notifications if you stuck a lot of code into the template, I'm not clear what type of statements can go into a template - php? html? .css? (You see how profound my ignorance is!). But Subscriptions gives you templates for each content type that are created automatically. That looks a better approach. And with Notifications, even if coding would sort the problem, it would nevertheless be beyond the reach of non-technical site-admins like me to do the coding.
Another big plus with Subscriptions is the option to select whether you want to be notified about comments and updates to nodes. With Notifications there is no option to select whether you get notified on an update. So if you have selected to be notified of a particular content type and someone is doing little tweaks to a node, you will keep on getting notified - including with the full body of the node if it has one (eg it could be an entire page). The one thing you don't want your site to do is bombard your users with stuff they may not really want. So that is quite a big one for me.
(Notify module is a pain there. I f you send out a newsletter, the users with Notify turned on will get the newsletter and a notification to tell them they are getting a newsletter! And if they have asked to be given the body of the content they will effectively get the newsletter twice. But let us at least take our hats of to Notify for giving you the option of title, title and teaser, and full body as simple radio buttons for the user.)
Admin-wise, Notifications functions are more scattered around and a little harder to find. But it is much better on queue processing, enabling you to interrogate the status of the queue, reset it etc. Not something you would need to do a lot maybe but good to have when you need it and particularly when you are testing. For example, when you are testing there might be problems with the environment that might interfere with notifications going out properly. By being able to interrogate the queue you get a better handle on where in the processing sny problem might lie. I couldn't find any comparable functionality in Subscriptions.
Watch out for "digests". Subscriptions digests are genuine digests, collating various items of content and presenting it in one email, but in Notifications it just seems to be a single line with a link back to the site. But that isn't really a digest in my view and it is not what a lot of users want. They don't want to have to go back to the site and login, they want the content right there in their email inbox. So this looks a big plus in favour of Subscriptions - unless, again, it is possible to do something more sophisticated with the templates in Notifications.
Overall, I thought subscriptions is closer to being the finished article, which makes the lack of html emails particularly frustrating. And it could do with admin functions for its queues. . Notifications strikes me as a bit more elegant in its architecture and more extensible but I think it could do with a little more focus on what users actually get from it eg the option to select notifications on updates or comments.
Quite a lot more testing to do for me, particularly on how multiple comments in a thread would appear - but I need to get the basics sorted out first.
If anyone can help me get nicely formatted content for different content types out of either of these modules I will be very grateful - to the extent of paying for it if necessary, because they are so fundamental to my site www.naepp.org.uk .
There's so much good stuff in these modules you have to want both of them to be successful. I'd love to see the best features of both in a single suite.
David Gibbens
Good points
Thanks for this thorough review, David!
After reading through all related pages and reviewing the code and concepts of these modules, I think that Notifications implements a much cleaner architecture design, since the actual sending of messages has been spinned-off into a pluggable Messaging API. So Notifications module itself does nothing more than it ought to do - focusing on notification queues, user interaction, and third party module integration. While there is probably no reason for Subscriptions to also adapt and rely on Messaging, it seems like Notifications has a better thought-out overall design already.
I'm currently investigating which framework I will implement for Guestbook module. So far, it looks like Notifications will be the right choice, since OG also integrates it, and Messaging already provides integration with Privatemsg module. Because a common community site built with Drupal consists of OG, Privatemsg, and (sometimes) Guestbook, it seems to be the way to go.
Thoughts?
Daniel F. Kudwien
unleashed mind
I'd prefer the same mechanism for OG and Project*
As someone who relies heavily on OG and Project* for different sites that I run, I'd definitely be happy to see the same mechanism adopted for both. Like David above, I've recently started looking to replace Notify, and started to delve into Subscriptions until I learned that Moshe had settled on Notifications for OG. Flickerfly's comments about keeping things open to other mechanisms besides email also resonate well for me.
Micah