Hello. I've updated the design page accordingly: http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationCenterforAppsImplementation#HIteration3
I'm going to implement this very soon so please write any remark as soon as possible. 2017-02-20 17:43 GMT+01:00 Vincent Massol <[email protected]>: > Hi, > > > On 20 Feb 2017, at 12:20, Guillaume Delhumeau < > [email protected]> wrote: > > > > 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”. > > [snip] > > > B - Create the NotificationUser entries lazily > > [snip] > > > C - Store the status on the client-side > > [snip] > > > 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? > > I’ve brainstormed with Guillaume and here’s the result of our thinking so > far: > > * Reuse the AS storage for sorting the events since it’s made for this. In > the future move to a noSQL storage (see http://markmail.org/message/ > 35crgocabxb3tfwk) > > * Create 2 new tables for: > ** Storing the audience for a given event. In one of the paramN fields of > the AS table, store the key to the audience table which lists all specific > users and groups to which the event is addressed to. When no audience is > specified it means it’s addressed to everyone. > ** Storing the read status per user. Note: Don’t store it in the browser > since this is too fragile and we want users to be able to switch device and > still keep their read statuses. > > * In the future move the audience and status data inside the nosql store > as properties. > > * In the future we should deprecate the watchlist since the Notification > Manager can handle this use case by considering that we can have an “app” > called “system” or “documents” that represents all documents in the wiki. > For each app we need to be able to specify to which events the user is > registering for, including the ability to specify fine-grained criteria > such as “Register for all new blog posts that contain the word ‘xwiki’ in > the title”. Thus the user should also be able to say “Register for all > document events located in the following wikis, spaces, pages”. > > * When an event is sent by an app, don’t create an entry in the status > table. Only create an entry there when a user marks an event as read. > > * So the idea is that the xwiki-platform-eventstream module should contain > only the storage of events (right now the storage is located in the AS > module) and then xwiki-platform-activitystream and > xwiki-platform-notifications both use it. It’s even likely IMO that the AS > could disappear as such and that it would be a special case of the > notification module. > > WDYT? > > Thanks > -Vincent > > > Thanks > > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
