Additional session table in the notifications database

[ncosta-ic]

What's this issue for?

We are currently working on an implementation enabling native desktop notifications provided through the web part of the notifications module (see #135).

The plan is to introduce a PHP based daemon providing the application logic to enable direct interaction with the web backend. After the initial usage in the notifications module, we essentially want to generalize it and move it over to the icingaweb2 module once it reaches a usable state supporting different requirements for other use-cases.

Now for the time being, it will be used in conjunction with the notifications module and its desktop notifications and we need to keep track of the currently authenticated sessions. As it does not really make sense to create a new database just for this limited and light-structured data, we want to make use of the existing notifications database, which brings me to the main point of this issue.

Additions to the codebase

An update of the schema/pgsql/schema.sql is needed to include the new table definition. Additionally, a schema/pgsql /upgrades/?.sql file for existing installations will be provided as well.

Are there any objections or architecturial choices from your part that speak against such a course of action?

[julianbrost]

Are there any objections or architecturial choices from your part that speak against such a course of action?

If the Go daemon can safely ignore that table, no. (I'll look over the schema change, if I find it strange, maybe you'll get a "are you sure this a good idea?" question, but that's about it. 😅)