Design Review

The overall design of the work is sound and has already been thoroughly reviewed by the Architect Council of that time period. The proposed concepts still remain valid and I don't see any reason to deviate significantly from the original design. However, two main things stand out as necessary to amend before we proceed with further work:

Need to decouple the eventing infrastructure from the notifications messaging infrastructure.
- Currently, the concepts of subscribers/publishers/channels are specific to notification-type messages. In other words, the system assumes that all subscribers are notification delivery channels, such as SMS, browser, etc.
- However, to create a scalable implementation that serves the multiple feature-sets and components of our platform, the underlying pub/sub framework should not assume the purpose of the subscribers. Rather, notification delivery channels can be built as a layer on top of the subscription layer.
Need to add an intermediary routing governance component that manages notifications across multiple channels.
- Without a configurable policy component that governs delivery of notifications across all channels, the user experience will be less from ideal if the user interacts with the system through multiple interfaces - email/mobile/web/etc.
- Currently, notification events are sent directly to delivery channels. Although a channel may have its own configurable delivery policy setting, it is myopic to its own channel and not considered within the context of its co-existence with the other registered channels.
- Ideally, the policy should be configurable by the learners, the course teams, and open-edX operators/admins.

Implementation Review

There are several usability features that were implemented for the in-browser notifications that are worthy of reusing. For instance:

Aggregating notifications so the user sees an aggregated count of the event, rather than individual events. For example, number of followers on your post.

There are also several scalability issues that are embedded in the core implementation that will not suffice for the edX scale. For instance:

Web site polls every 30 seconds to find new notifications
Polling to find pending notifications
Signal to trigger publishers to register

There are some code maintenance issues that would need to be improved. For instance:

Management command to fire notifications
Mocking (duplicating) urls.py
django.contrib.messages.middleware.MessageMiddleware is installed but doesn't seem to be used.

Browser not supported