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

Mon Oct 29 12:04:24 UTC 2012

On Fri, 26 Oct 2012 12:43:06 +0200, Sean Hammond <sean.hammond at okfn.org>  
wrote:

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

Hi,

I spend some time to figure out how to make a pull notifier most  
extensible.

When we go for the pull model, I would suggest that we use the following  
(package) structure:

notifier/
  - notifier.py

  - notification.py

  - notifiers/
      - activity_stream.py
      - general_announcements.py
      - to_admins.py
      - etc.

  - methods/
      - Email.py
      - Twitter.py
      - etc.

  - presentations/
     - email_activities.py
     - email_general.py
     - email_to_admins.py
     - twitter_general.py

in pseudo code:

def notify(self):
  - init methods (Email, Twitter, etc., maybe special for each  
notifier_class)

  - for notifier_class in notifier_classes:
	notifier = notifier_class()

         notifier.set_methods(methods[notifier_class])
         notifier.notify()

each module contains a interface like this

def set_methods(self, methods)
def notify(self)
   #determine users concerned
   # for each user concerned
   # create a notification
   # call for each method the send method
   # method.send(notification)

each sender contains a interface like this:

def send(self, notification)
    # look up presentation (when there is none, dismiss the notification)
    # apply presentation (structured data -> email subject string, email  
content string, email content-type, etc.)
    # perform sending

each presentation contains a interface like this:

def apply(self, notification)
   # return a email, tweet, whatsoever

(additionally it could be configurable e.g. to let users decide whether  
they want plain text emails or HTML emails, but that might not be  
important for now)

notification class could also just be a dictionary (so no class needed)  
with the following attributes:

'receiver' - user object: each method should be able to extract the  
appropriate address (email address, twitter name, etc.)
'type' - a type of the notification ('activity', 'changes in  
subscriptions', 'general', etc.)
'data' - type-specific data: important for presentation modules to build  
email or tweet

Cheers.