We need to select a base module for Activity stream functionality.
It seems like our choices are between:
- Activity log
- Heartbeat
- Message
For a detailed comparison between these modules, see http://groups.drupal.org/node/15207.
As part of the Commons 3.x MVP, the kinds of activity that should show up in an activity stream is described at https://docs.google.com/a/acquia.com/spreadsheet/ccc?key=0AqCiMWdwdDYJdF....
My sense is that Message module is the best choice for Commons because:
- It has a flexible architecture that is fully exportable based on the entity system.
- It controls display of Messages via Views
- It determines Message visibility at view time, rather than at log time. As I understand (and according to the wiki above), both Heartbeat and Activity log determine message visibility at log time. Determining message visibility at log time rather than view time has been a major pain point of Activity log.
- Variables in activity messages (such as node title, username) are accurate as of message view time, rather than Message log time (Unlike Heartbeat)
It also provides easy-to-configure translation support via i18n.
We could build a Common_stream module based on Message that provides integration with the site actions we wish to support in the stream. Ideally, we would make this integration powered by Rules as much as possible. However, my sense is that, at least with the current status of Message, it's easier as a developer to write the necessary integration via code than via Rules.
My preference for building the streams in a Rules-based way where possible is because it lets us provide more flexibility to site builders, who could customize and override exported rules.
Note that with Message, regardless of whether the integrations are based on rules or hard-coded, the contents of the message, Views that display the messages, and translatability of the messages are retained.
Comments
Comment #1
iribarne commentedPer Amitaibu's demo of the Message module during the Commons BoF at DrupalCon Denver, my vote is for the Message module. It leverages the Entity API and has support for Views.
Comment #2
izkreny commentedI'm also voting for Message, mainly because translation support and Message notify - Multilingual email notifications.
Also, it looks like the most sexy module of above mentioned, despite, or better: because of his age. :P
Comment #3
isellakuria commentedWhat about the Facebook-style Statuses (Microblog) module? We are currently using it on our site and I think is essential for a social networking site.
Comment #4
izkreny commented@isellakuria: we are talking here about activity logging module, not status updates / microblog feature.
Although they are tight connected, they are two different categories so status updates / microblog feature should be a separate issue / feature request, IMHO.
BTW, Facebook-style Statuses (Microblog) is only for D6, D7 version has new name: Statuses (Social Microblog).
Comment #5
ezra-g commentedMarking as "needs review" based on the OP proposal to use Message module as the basis for this functionality. Per, #1512846: Commons position on Open App Standard, I would like to build the stream integration as a standalone contrib module.
Comment #6
icecreamyou commentedI would have appreciated being told about this.
The bottom line is that I hit a wall with Activity Log after leaving Acquia. The concept is good and it does things that Message can't with its current architecture, but it's such a huge undertaking that I wasn't able to put the necessary time into it to make the changes it needed to get to where I wanted it to be. When I was working full-time at Acquia it was feasible to put that time in, but it wasn't feasible as a student. So now it's in a situation where it should really be completely rewritten for D7, and frankly I'm not even sure the same mechanisms that made some of its functionality possible in D6 are still there in Rules for D7. I don't know when you guys will actually start developing Commons 7.x-3.x, but my feeling is that if you chose to go with Activity Log, a D7 port wouldn't be stable by the time you wanted to start working. And if you don't choose to go with Activity Log, I probably won't port it to D7, though I'll be available to help with an upgrade path especially once I get back to Acquia in late July.
That said, I've noted before that the comparison you're using is inaccurate. This comparison contains an accurate list of things that actually matter to users (though the situation for the other modules may have changed since then). And looking at the Activity Log queue there are only about 12 issues I think are significant impediments to a very good activity stream experience, many of which are actually adding features; and given that no new issues have been submitted in 3 months, I think that's a pretty reasonable count. On the other hand I have to admit that I would be relieved if I didn't have to maintain Activity Log in its current form any more.
Between Heartbeat and Message, I like the Message architecture better. The last time I read the Heartbeat code it looked like several major features had been added on as afterthoughts rather than as part of an overall cohesive structure. There is no doubt it does some nice things, and Stalski has done a good job maintaining it, but Message is just cleaner IMO and relies more on Drupalisms rather than doing everything itself. However, I wouldn't expect everything to "just work." None of the 3 modules being considered ever quite figured out an administrative interface that was easy to understand, and Message does have some limitations.
I should also note that maintaining default message templates in Rules ended up being way more of a pain than I expected, just because diffs never seemed to come out as cleanly as expected. As a result, when I wanted to make a change to the templates, I would typically do it by manually editing the exported Rules. And Rules itself is a pain point there too because of how aggressively it caches everything.
Activity is another activity stream module not mentioned in this thread -- Heartbeat took a similar high-level approach here but is better maintained.
Comment #7
ezra-g commentedHi IceCreamYou,
Thanks for the thoughtful response - There's a lot here so I wanted to respond point by point.
I called you over Skype November, 2011 and in that conversation shared that we were considering using Message module to power the activity stream functionality, and to invite you to join us in helping with that effort.
Totally understood. To be clear, you got an amazing amount of work done in your Summer at Acquia and everyone appreciates that work. The fact that we're considering Message for Drupal 7 is definitely not a criticism of your work and I hope you don't perceive it that way. As you point out, Activity log would essentially need to be rewritten, either as part of #1259306: Re-architect activity message visibility or simply as part of the update to Drupal 7.
There's a bit of irony here: There was a community wiki to compare modules that serve a duplicate purpose and look for opportunities for maintainers to join forces. The wiki had input from ~10 contributors and in the end, that wiki whose purpose was to avoid unnecessary duplication was itself duplicated.
It's also hard to revise the collaborative chart without specific criticism of where it's inaccurate.
Regarding the "things that actually matter to users", I think your comparison is inaccurate in a few areas, or perhaps just out of date:
Message supports grouping - it just happens on the part of the module implementing the Message API. For more details, see #1538736: Message grouping.
Message lays the foundation for email digests that support multiple languages.
See http://www.gizra.com/content/message-notify-multilingual-email-notificat... and http://drupal.org/sandbox/amitaibu/1541934 .
This could be supported similar to the way you did for Activity log: Provide Radioactivity integration for individual messages.
Activity is mentioned in the wiki comparison I referenced and excluded for the reasons you mentioned.
I hope that helps to clarify the thinking behind considering Message. Between the complexi requirements for activity streams on an Organic groups-enabled site and the fact that Message is still relatively young as an API, I fully expect to have a few head scratching moments with any solution we chose.
My hope is that you'll join us and help apply your experience as we continute to work towards solutions :).
Retitling the issue to reflect the current proposal.
Comment #8
icecreamyou commentedRight, no hard feelings. I just meant I would have liked to have been told about this particular issue so I could have jumped in earlier.
That is certainly not an understatement. :-) The challenges do make for some fun problems though.
I'm of course happy to offer insight into the challenges I faced and how I overcame them (or would have overcome them...) especially when I return to Acquia at the end of July. I think it's unlikely that I'll be able to contribute (much?) code directly towards Message, though there may be related initiatives I might work on.
Comment #9
crimsondryad commentedI'm for using Message API and it seems other folks are leaning that direction too. Marking RTBC.
Comment #10
amitaibuNote that Kickstart2 now also includes Message & Message notify
Comment #11
ezra-g commentedBased on the discussion above, this is fixed.