Notification system (RENOP)

[paulr34]

This is a Draft PR for the notification framework.

TODO:

1. Decide how the querying of SESSION_NOTICE table will be implemented.
   OPTIONS:
   A. Notifications should be able to be triggered at any moment. Therefore, it would make sense to have interval polling which constantly checks for new notifications. This is not in the PR but I have this working locally. Although this code is out of date, here is an example of how it might work 57d9486
   B. If notifications are not able to be triggered at any moment and are specific for importing and exporting .zap files then there could be a function which queries the SESSION_NOTICE table after importing. This way there would be no need for polling. Basically, the notifications would only be queried when creating a session...
   C. Both A and B

2. Add notification page to the front end

3. Test

[brdandu]

This is a Draft PR for the notification framework.

TODO:

1. Decide how the querying of SESSION_NOTICE table will be implemented.
   OPTIONS:
   A. Notifications should be able to be triggered at any moment. Therefore, it would make sense to have interval polling which constantly checks for new notifications. This is not in the PR but I have this working locally. Although this code is out of date, here is an example of how it might work 57d9486
   B. If notifications are not able to be triggered at any moment and are specific for importing and exporting .zap files then there could be a function at the end of importing a file which queries the SESSION_NOTICE table. This way there would be no need for polling. Basically, the notifications would only be queried when creating a session...
   C. Both A and B
2. Add notification page to the front end
3. Test

This whole triggering the notification table makes it complicated in my opinion. How about we just introduce an additional pane along with our menu bar

In here we could have another icon for notifications. If a user clicks on this then we can show all the notifications for that session. This can simply show the results of "getNotification". To make it better if we want to alert the user regarding notifications then this notification icon can be turned to red until the user presses this once. Once they press it then it can go back to say yellow. If a new notification enters the session notice table again then turn this back to red until the user presses on it again.
For when do we turn the notification icon to red? => I would say every time there is a new entry to the session_notice table for that session.
My understanding is this should not require any kind of polling mechanism. Just the UI reflecting on the state of the backend.

[paulr34]

This is a Draft PR for the notification framework.
TODO:

1. Decide how the querying of SESSION_NOTICE table will be implemented.
   OPTIONS:
   A. Notifications should be able to be triggered at any moment. Therefore, it would make sense to have interval polling which constantly checks for new notifications. This is not in the PR but I have this working locally. Although this code is out of date, here is an example of how it might work 57d9486
   B. If notifications are not able to be triggered at any moment and are specific for importing and exporting .zap files then there could be a function at the end of importing a file which queries the SESSION_NOTICE table. This way there would be no need for polling. Basically, the notifications would only be queried when creating a session...
   C. Both A and B
2. Add notification page to the front end
3. Test

This whole triggering the notification table makes it complicated in my opinion. How about we just introduce an additional pane along with our menu bar In here we could have another icon for notifications. If a user clicks on this then we can show all the notifications for that session. This can simply show the results of "getNotification". To make it better if we want to alert the user regarding notifications then this notification icon can be turned to red until the user presses this once. Once they press it then it can go back to say yellow. If a new notification enters the session notice table again then turn this back to red until the user presses on it again. For when do we turn the notification icon to red? => I would say every time there is a new entry to the session_notice table for that session. My understanding is this should not require any kind of polling mechanism. Just the UI reflecting on the state of the backend.

That is an interesting idea. It would keep the user from being bombarded with notifications especially if they just upgraded their extremely old .zap file.

Re: "For when do we turn the notification icon to red? => I would say every time there is a new entry to the session_notice table for that session. My understanding is this should not require any kind of polling mechanism. Just the UI reflecting on the state of the backend." How would the front end know if a new notification was added to the table without polling? Unless it only queries during the creation of a session or in other words at fixed moments, there would need to be an interval polling mechanism.

Case 1: POLLING (This is how the DIRTY FLAG works)
1.) User is playing around with their .zap file and messes up big time.
2.) The back end then creates a new entry in the table pointing at that sessionID
3.) Since the back end periodically polls that table, it will know to communicate to the front end that there is a new notification.

Case 2: NOT POLLING
1.) User imports old .zap file with lots of upgrades which create notifications in the table
2.) After importing, a query is called to get all of the notifications that were created.
3.) The front end displays them somehow someway

Basically, as far as I can tell, if the user can cause a change that requires an addition to the SESSION_NOTICE table at any random moment then we will need a polling mechanism. If not, then we can put a query in a line of code after all possible notifications have been created.

[brdandu]

This is a Draft PR for the notification framework.
TODO:

1. Decide how the querying of SESSION_NOTICE table will be implemented.
   OPTIONS:
   A. Notifications should be able to be triggered at any moment. Therefore, it would make sense to have interval polling which constantly checks for new notifications. This is not in the PR but I have this working locally. Although this code is out of date, here is an example of how it might work 57d9486
   B. If notifications are not able to be triggered at any moment and are specific for importing and exporting .zap files then there could be a function at the end of importing a file which queries the SESSION_NOTICE table. This way there would be no need for polling. Basically, the notifications would only be queried when creating a session...
   C. Both A and B
2. Add notification page to the front end
3. Test

This whole triggering the notification table makes it complicated in my opinion. How about we just introduce an additional pane along with our menu bar In here we could have another icon for notifications. If a user clicks on this then we can show all the notifications for that session. This can simply show the results of "getNotification". To make it better if we want to alert the user regarding notifications then this notification icon can be turned to red until the user presses this once. Once they press it then it can go back to say yellow. If a new notification enters the session notice table again then turn this back to red until the user presses on it again. For when do we turn the notification icon to red? => I would say every time there is a new entry to the session_notice table for that session. My understanding is this should not require any kind of polling mechanism. Just the UI reflecting on the state of the backend.

That is an interesting idea. It would keep the user from being bombarded with notifications especially if they just upgraded their extremely old .zap file.

Re: "For when do we turn the notification icon to red? => I would say every time there is a new entry to the session_notice table for that session. My understanding is this should not require any kind of polling mechanism. Just the UI reflecting on the state of the backend." How would the front end know if a new notification was added to the table without polling? Unless it only queries during the creation of a session or in other words at fixed moments, there would need to be an interval polling mechanism.

Case 1: POLLING (This is how the DIRTY FLAG works) 1.) User is playing around with their .zap file and messes up big time. 2.) The back end then creates a new entry in the table pointing at that sessionID 3.) Since the back end periodically polls that table, it will know to communicate to the front end that there is a new notification.

Case 2: NOT POLLING 1.) User imports old .zap file with lots of upgrades which create notifications in the table 2.) After importing, a query is called to get all of the notifications that were created. 3.) The front end displays them somehow someway

Basically, as far as I can tell, if the user can cause a change that requires an addition to the SESSION_NOTICE table at any random moment then we will need a polling mechanism. If not, then we can put a query in a line of code after all possible notifications have been created.

For turning the colors of the notification icon, I was hoping there is some form of server push notification to the client which can just do this. Can we use the web socket to throw a push notification(from the backend/server) when there is a new entry in the session_notice table? The browser/ui can update when it gets this notification. I am not thinking of this as a polling mechanism but just an open connection for client and server to interact using the web socket. However, yes we do need a polling mechanism on the client or an open connection between client and server to update tell the user there are new notifications.

[jingteng25742]

For turning the colors of the notification icon, I was hoping there is some form of server push notification to the client which can just do this. Can we use the web socket to throw a push notification(from the backend/server) when there is a new entry in the session_notice table? The browser/ui can update when it gets this notification. I am not thinking of this as a polling mechanism but just an open connection for client and server to interact using the web socket. However, yes we do need a polling mechanism on the client or an open connection between client and server to update tell the user there are new notifications.

We already have the web socket notification scheme setup since it was necessary for Studio integration.
For the flow of the DIRTY FLAG, it was necessary due to how Studio/Eclipse's dirty flag worked internally.
For the notification, I like @brdandu 's idea of a notification icon / window for listing all notifications. e.g. similar to social media event history.
For init features like opening .zap, the notification can be pushed during some init phase and rest can be all async'ed based. We should use DB "TRIGGER" / API wrapper to watch / trigger operations to the DB if polling was only required for this reason.

[paulr34]

For turning the colors of the notification icon, I was hoping there is some form of server push notification to the client which can just do this. Can we use the web socket to throw a push notification(from the backend/server) when there is a new entry in the session_notice table? The browser/ui can update when it gets this notification. I am not thinking of this as a polling mechanism but just an open connection for client and server to interact using the web socket. However, yes we do need a polling mechanism on the client or an open connection between client and server to update tell the user there are new notifications.

We already have the web socket notification scheme setup since it was necessary for Studio integration. For the flow of the DIRTY FLAG, it was necessary due to how Studio/Eclipse's dirty flag worked internally. For the notification, I like @brdandu 's idea of a notification icon / window for listing all notifications. e.g. similar to social media event history. For init features like opening .zap, the notification can be pushed during some init phase and rest can be all async'ed based. We should use DB "TRIGGER" / API wrapper to watch / trigger operations to the DB if polling was only required for this reason.

Triggering a change to the database works for changing the SESSION_NOTICE table but how would the front end know that the SESSION_NOTICE table was changed without constantly checking it?

We could have a DB trigger execute a function which communicated with the front end but this has not been implemented before while using an interval for polling the DB is already implemented.

As far as I can tell, the difference between the DIRTY FLAG and other notifications you mention is that the DIRTY FLAG can be changed at any moment rather than at a fixed moment. This is why I have used it as a model for this project. My assumption is we want a system where a notification can be created and used at any moment.

I also like the notification idea.