Real-time notification

(Cédric Krier) #6

One potential issue with “LISTEN/NOTIFY” is that it takes permanently a connection resource on the database per long polling. So the number of active client that a server can support will drop quickly with this feature.
A possible solution will be to have one thread per process that listen on a generic channel, each long polling request from the same process will register to this thread. Once the listen thread receive a notification, it dispatches it to the right long polling thread. The inconvenient of this method is that the listen thread will receive all notifications even for users who does not have a long polling thread registered. This could be improved by having the listen thread listen to each channel of the long polling thread.

(Cédric Krier) #7

Maybe a solution will be to have a separate process that listen on a specific port (server should sent the address or the port at the client login). This process will not be threaded but instead just asynchronous. It will use a connection per database and it will listen for all the requested channels. It will use a single event loop for new long polling connection and database notify and it will dispatch the notification to the right request.

(Sergi Almacellas Abellana) #8

A part from the protocol to comunicate with the server i think that it should be possible to relate the notification to some records and the user should be able to access does records with a single click.

For example: I do some long task in async way and I will like to notice the user when it have been finished. As this task may be related to a record the user may be able to open the record (in a new tab) directly when the notification is shown.

(Cédric Krier) #9

I do not think it is possible to click on a notification.

(Sergi Almacellas Abellana) #10

If we have to write a separate server solution I think we can now use a standard protocol (like websocket as @edbo suggested).

There is a python implemenation of the websocket protocol which supports python2.7, a python implementation for the server side which is only available on >3.4 version (3.3 with asyncio library) and it’s also available as native javascript.

For me adding new features only to users of python3.4 will incentive the movement to the newer python versions.

(Sergi Almacellas Abellana) #11

On my system I have notifications that have some buttons to click and do some actions related to them. An for what I read in the libnotify is possible to add Actions, and in case the system does not support them we can use a HyperLink with the tryton URL as fallback.

(Cédric Krier) #12

By why websocket? I see no advantages for this protocol because notification is any way in one direction server → client. Also with websocket, you just have something like a socket so you have to create your own protocol on top of it.
So to consider websocket, I need to have a rational for its usage and not just because it is a new cool kid.

This could be done only with a common protocol for all notification systems.


To me it has nothing to do with “new cool kid” because it isn’t a cool kid. It’s hard to implement because of it’s asynchronous nature. Websockets can also be used as “normal” connection. And because Tryton uses RPC, that can be transported by Websockets without a problem. But mostly there is a fallback to HTTP because not all browser support websockets.
By using websockets you lift the system out of the database like you want to do with the LISTEN / NOTIFY functions of PostgreSQL. Websockets gives you also the possibility to do some user-actions like sending notifications to a user from a module.

That’s exactly what I’m thinking of! E.g. print a complex report or do a long-running operation like reconciliation or open the chart of accounts etc. You are then be able to give the user status updates during the process of collecting data or printing. I’m also thinking of voip integration, so when the phone starts ringing, the user gets a notification who it is. Eventually the client can already open a new tab with the caller details.

But maybe I’m a bit of there … :grin:

(Cédric Krier) #14

I do not want to move out of the database. Tryton is a transactional system, it needs the database and it needs a transactional notification system.

On more reason to not use it.

No you wont because of the transactional nature of Tryton.

Nothing to do with server notification. Your soft-phone can just query the client for that.


This isn’t also easy at all.

Please don’t open extra ports! It’s always a security risk and Tryton starts to look like other cool new software where you must open a lot of ports to get the software running with the (new) features.

(Cédric Krier) #16

I can not understand the rational behind that. But of course it is always simpler to configure if there is only one port.

(Cédric Krier) #17

I think the notification protocol should be flexible and not only limited to notification popup.
Indeed I think we should be able to send to the client action like reload this records, execute this action etc. This way we could get the client refreshing automatically records that were opened before a modification on the server side.


I just stumbled onto Is this something we can use for this?

(Nicolas Évrard) #19

Since libnotify does not seem to be available for windows I made some search and found this SO question:

What bothers me after looking the code is that it’s basically just another window managed by tryton not at all something as well integrated as libnotify seems to be.

For macos it’s also the same kind of issue. People usually call some shell script or use libraries directly interacting with the OS but at least it’s a bit more integrated.

(Cédric Krier) #20

Well pywin32 is packaged on mingw:
So there will be no issue to use it. But I think it will be better to write our own version than using Windows-10-Toast-Notifications.

FYI, there is no terminal-notifier application on our OSX.

PyObjC is not packaged by brew but it seems it can be installed via pip:

So I see no major issue.

(Cédric Krier) #21

Indeed I think we should use GNotification because it is a cross-platform implementation. It will require to migration the client to GtkApplication. But it is not a bad thing because this will bring more possibilities of improvement in the future.

(Cédric Krier) #22

GNotification has no backend yet for Windows:
and old version of glib even crashes if it is used so we will need to implement custom code and not call send_notification under windows.
And it does not seem to work currently on OSX (but backend is implemented).
So I still think we should use GtkApplication because:

  • backend may be implemented one day
  • it will allow to remove custom IPC code (but it does not work for OSX which any way was not fully functional)
  • we will benefit from future improvements (because it is the GTK recommended way)
  • it will probably fix issue6995

(Cédric Krier) #23

I’m not sure that the session is the right object to use because it expires. I think it will be better if the client generate a random ID. This ID will be put in the context of each request and it will survive to a session timeout (indeed until the page is reloaded for sao or the application is closed for tryton).

(Cédric Krier) #24

As the session will be used to authenticate the long polling request. It is needed that the session has a long validity period and not the default 10min. This will be implemented by Double session timeout

Double session timeout
(Cédric Krier) #25

This topic was automatically closed after 13 days. New replies are no longer allowed.