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

[Sven R. Kunze]

On Tue, 23 Oct 2012 13:33:21 +0200, Sean Hammond <sean.hammond at okfn.org>  
wrote:

> 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.


> If we have a centralised approach that somehow infers notifications from
> data in the db, then code throughout CKAN code "unintentionally" spawn
> notifications by making some innocent db change that then triggers the
> notifier to infer a notification from it. Here I think it might really
> become difficult to track which lines of code throughout CKAN are
> triggering notifications.

I am sorry; I disagree. One just has to have a closer look at ONE single  
place as the rest of CKAN is totally unaware of notifications (this is the  
advantage when decoupling things). So, the rest of CKAN cannot behave  
wrongly in terms of notifications. However, that notifier can.


Anyway, I'd be interested in the data that be stored in the notification's  
queue.

"What columns should the unsent_notifications table have? user (id or name  
of the user to notify), type (the type of notification e.g. activity  
stream, determines what notification renderer is used to render the email  
body), content"

When we store the user for each row, it might get a really large table as  
we duplicate entries just for different users (especially when 'content'  
is really big; e.g. when transmitting longer posts/announcements etc.).  
When don't, we have to do the job (sorting out which users to be informed)  
in the notifier (which'd have the advantage of being more up-to-date  
regarding user's interests (following, subscriptions)). When having such  
logic in the notifier why not deciding the notifier itself, what the  
content to be sent should be?

Why storing so many data in the notifications queue that might never be  
used?
We'd like to have digest mail that simply informs the user that he has  
unseen activities somewhere on CKAN (same logic as on-site notifications,  
so it could be re-used). Just when there is only a single activity for a  
while than we could mail it to the user directly as is. But once there are  
more than one, nobody really wants to see these in a mail but only a link  
to CKAN with an explanation.
Again, we have much logic in the notifier just to sort out which users and  
to refine the items in the queue in order to present a reasonable amount  
email content.

 From this it's only a small step to add to the notifier the logic of  
whether or not a email should be sent at all and whether this email is  
about an activity stream or an announcement from CKAN or something else.


Best regards.