Hello XWikiers. In the current roadmap, I have the responsibility to create a notification system.
The need has been described in the following page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationSystemforApps In a few words, applications need to send some messages that could be displayed either on the top menu (the "notification" menu we already have and where the Watchlist options are located) or by e-mail. Users should see quickly the new messages and have the ability to mark some messages has read. Use-cases: having a notification when a new message has been posted on the Forum application, having a notification when the user has been invited to join a wiki, having a notification when a new meeting is organized, etc... Users will also have the ability select which type of notifications she wants to receive. Displaying messages is not the difficult part. Neither is sending emails. What is complicated is the storage of them. Since a user should still see messages she marked as read, we need to store the status of each notification for each user. It could be done either on the server-side (in a NotificationUser table), either on the client-side (using local storage: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). I actually see 3 ways to implement the storage: A - When a notification is sent, a job creates all the NotificationUser entries needed (1 per user) with the status "unread". =============================================================================== Pros: * It's quick and easy to retrieve the list of notifications when a user requests a page: all we have to look at is the NotificationUser entries. Cons: * The creation of NotificationUsers entries could take time so notifications will not really be in real-time. * With a lot of users, it creates a LOT of NotificationUsers entries. To avoid having a delay between the sending of a notification and the displaying of it, we can have an in-memory storage in addition to the database storage, which store notifications until they are written in the database. Note: of course, old notifications (even unread) are periodically removed from the database to limit disk usage. B - Create the NotificationUser entries lazily ============================================== When a user requests the list of notifications, we actually look at all notifications and see if they concern the current user. Then, we create NotificationUser entries if some of them are missing. Pros: * In a wiki with a lot of inactive users, we actually store less NotificationUser entries. Cons: * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). C - Store the status on the client-side ======================================= When a user requests the list of notifications, again we look at all notifications and see if they concern the current user. Then, it's the browser which store the "read" status on its local storage. Pros: * We do not store the NotificationUser entries (that can take a lot of places) Cons: * If user changes its browser, she loses all her notifications' status (maybe not that problematic) * Everytime a user requests the list of notification, we actually need to do the business logic of collecting notifications for the user (more CPU used). On this page: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationCenterforAppsImplementation I have explained they way I consider the implementation. There is a notion of NotificationType for example that might interest you. I'm hesitating between option A and C. I think B has no really benefits. The rest of the mechanism can be implemented right away, so I'm starting it. Please answer quickly if you think I am doing something wrong. What do you think? Thanks -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
