[ckan-dev] RFC: Activity streams on-site and email notifications

Fri Oct 26 10:43:06 UTC 2012

> Well, we already have a logic function that retrieves the list of
> activities for a user (their dashboard activity stream), so I suppose we
> could just store the time when the last activity streams notification
> email was sent to the user, and then when we come to send that user
> another notification we just find the activities from their stream since
> the time of the last email. We would find the activities using an
> activity streams logic function though, not by reading the activity
> streams database tables or accessing the activity streams model code
> (that would be tight-coupling).
> 
> So instead of the activity streams module pushing notifications onto the
> queue (as in my design) you have the email notifications module pulling
> activities from the activity streams.
> 
> Honestly, I think I prefer the push model, because if I am adding a new
> feature and I want email notifications for my feature then all I need to
> do is call the email_notification_create() logic function from my code,
> I don't need to know anything about how email notifications are
> implemented in CKAN, so things are nice and modular and I only need to
> add code to my own new module. In the pull model, as well as adding my
> new feature in its own module I would have to understand and edit the
> email notifications module to make it pull in notifications from my new
> module.
> 
> Neither approach is tightly-coupled by the way, as long as the different
> modules such as activity streams and email notifications always interact
> with each other through well-defined interfaces such as logic functions,
> and not by accessing each others data structures or database tables.

One thought I had about all this, in the push model when e.g.
group_create() is called and group_create() calls activity_create() to
create a "seanh created the new group foobar" activity, either
group_create() or activity_create() needs to call
email_notification_create() to push an email onto the queue. But the
question is, which users should the email notification be addressed to?

When activity stream activities are created they aren't addressed to any
users. It's only when you call the dashboard_acitivity_list() function
to get a user's activity stream that it decides which activities that
user should get. Which activities are "addressed to" which users is
defined by the dashboard_acitivity_list() function.

I think the pull model solves this better as when the notifier job is
running it just calls dashboard_acitivity_list() to pull out the
activities for a given user and then emails that user about any new
activities. It would have to loop over every user on the site every time
it runs, but that might not be so bad as it's a background job.