Quantcast

[Proposal] Implement a Notification Center

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proposal] Implement a Notification Center

Guillaume Delhumeau
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 ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Implement a Notification Center

vmassol
Administrator
Hi,

> On 20 Feb 2017, at 12:20, Guillaume Delhumeau <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Implement a Notification Center

Guillaume Delhumeau
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 <[hidden email]>:

> Hi,
>
> > On 20 Feb 2017, at 12:20, Guillaume Delhumeau <
> [hidden email]> 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 ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Loading...