There's a comparison of Activity stream modules in the "Similar module review' group: http://groups.drupal.org/node/15207 .

@Amitaibu, it would be great to get the key areas of that chart filled in :).

My goal here is to better understand the differences between the major modules and, where possible, try to get the various sharp minds working on this problem working together as much as possible.

So far, myself and Stalski have been filling data in the chart.

Thanks!

Comments

amitaibu’s picture

* Message is an API module that heavily relies on Entity API (and metadata)
* Its just about creating messages. It allows others (read as Views) to show the messages.
* Unlike HB (Heartbeat) it doesn't have its own query builder (which is necessary to allow collapsing messages together).

What I like about heartbeat is that is works and gives a solution. However, I feel that its doing more than it needs to. The CTools which is an entity is an example that in its core, the API isn't very clean.

I think that we can surely join forces. HB can leverage the Message API and be a query builder.
Message streams are hard, so we can really gain from having several people thinking through all those stuff together :)

mototribe’s picture

I would love to see a more simple "activity feed" module that is robust, somewhat flexible but not overly complicated. Drupal sites should be able to easily leverage "Facebook" type functionality.
Any progress in talking with Stalski about joining forces/

rooby’s picture

Message streams are hard, so we can really gain from having several people thinking through all those stuff together :)

Isn't this handled by views? You can make whatever streams you like with messages and views.

I would love to see a more simple "activity feed" module that is robust, somewhat flexible but not overly complicated.

The problem is you can't really get flexibility and out of the box functionality and simplicity all at once. Because the more you try to let people do out of the box the more assumptions you have to make about what people want to do with it. That is the problem I ran into with other modules. They assume too much about what I want to do with it so that I have to fight against it do get it to do exactly what I want.

The message module is simple and very generic, meaning you can do basically anything you want with it. The downside is it doesn't do anything out of the box, so you have to do it yourself with code, which is too big a hurdle for a lot of people.

I think the ideal solution is that message be the base API and then we can have multiple modules that build on top of it to provide a solution for a specific use case, for example heartbeat could be a facebook activity stream module built using message, and there could be other modules with different focuses, all built on top of message.
Then the user just finds the one that matches their use case.

And because message is strictly an API, the people who want something more custom don't have to have the bloat of out of the box features they don't need, they can just use message and their custom code.

I think that is the best solution for the most people and from reading various posts on d.o and g.d.o and elsewhere, I think that is what the message maintainer is aiming for.

[edit] fixed a typo.

amitaibu’s picture

@rooby, Amen! :)

mototribe’s picture

I like that idea a lot. Is it difficult to transform message into an API?

rooby’s picture

Message already is the API. It is only an API and nothing else.

If you download it and have a look at the message_example module that is included you can get an idea of how to use it.

Basically message gives you the framwork to create messages.
You create message types via the UI like you would do for a content type.
Message types are things like create_content, update_content update_user etc.

In it's simplest form a message type is made up of message text containing tokens, then when you create a message you pass in the values for the tokens, which can either be a hard coded value or a callback to generate the value at the time the message is viewed.
However because message types are an entity you can also add additional fields to them and do more complex things.

Then in your custom module you create messages of certain types. For example, you can use hook_node_insert() to create a message of type create_content and hook_user_update() to create a message of type update_user.

Then to create activity streams you can use message's views integration to create message views showing whatever activity you desire.

It will become easier when people contribute some modules that work on top of message so you don't have to write custom code.

For a slightly more advanced usage see the message_notify module. Although keep in mind it is also an API type module and doesn't provide end user functionality out of the box.

mototribe’s picture

Hi rooby,
thanks for the detailed reply. I'm interested and will give it a try. Heartbeat was just way to complex and buggy for me

rooby’s picture

No worries.
I had similar problems. It would be great if you wanted exactly what it provides, but if not it makes your life hard.

message is simpler and cleaner, so long as you don't mind doing a little coding.
And if you need help with the coding there is the issue queue and stackexchange.

I also have notification requirements, including search_api_saved_searches notifications. Because of the flexibility of message I will be able to run all my notifications through message, message_notify & some custom code for non-email notification types. That means I can avoid the bloat of the messaging (not message) & notifications suite of modules, which aren't fully ready for drupal 7 yet anyway.

Needless to say, making the switch to message this week has made me very happy as I was burning a lot of time bug fixing with other modules.

Andre-B’s picture

I am currently working on a message notification center: https://drupal.org/sandbox/baumeier.it/2078043 I have all known bugs fixed and will work on documentation and the remaining wishlist.MD entries next. There's a screencast showing the basic functionality, but it's from the earlier prototypes. The current status has more features and configuration options. Any feedback and help is appreciated. (even later when this goes into "application for full project access".

bluegeek9’s picture

Issue summary: View changes
Status: Active » Closed (outdated)