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

[Sean Hammond]

> >Personally I like the idea of a single unsent notifications queue and a
> >logic action function for adding something to the queue. Yes the action
> >function could then be called from many places in CKAN (other action
> >functions, controllers, templates or template helper functions,
> >extensions, by a user via the action API...), but I don't think it
> >should be too difficult to track where notifications are coming from
> >because they all have to go through this logic action function, so you
> >just look for calls to this function. (And to be honest, this is true of
> >other logic action functions in CKAN as well, such as spawning
> >activities that appear in activity streams.)
> 
> Yes, I've seen that in the code which indeed is also bad design in
> terms of decoupling things. However, these are already there, so
> never change running system.
> 
> It's not, that we can't do it that way, but that this way would
> couple things tightly together which I'd rather like to avoid as it
> imposes a thread to maintainability.

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.

I take your point about the content of the notifications table, that
needs more thought. We may want to send the same notification to many
users, e.g. if a dataset is changed all users who follow that dataset
get notified, so perhaps the user column should be a list of user names.
It needs more thought anyway.