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.
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.
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.
I do not think it is possible to click on a notification.
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.
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.
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 … 
1 Like
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.
I can not understand the rational behind that. But of course it is always simpler to configure if there is only one port.
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.
1 Like
Since libnotify does not seem to be available for windows I made some search and found this SO question: windows - Notification using python - Stack Overflow
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.
Well pywin32 is packaged on mingw: MINGW-packages/mingw-w64-python-pywin32 at master · Alexpux/MINGW-packages · GitHub
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: https://pythonhosted.org/pyobjc/install.html
So I see no major issue.
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.
1 Like
GNotification has no backend yet for Windows: https://gitlab.gnome.org/GNOME/glib/issues/1234
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
1 Like
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).
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
This topic was automatically closed after 13 days. New replies are no longer allowed.