Scott wrote:

VNotifications intrigue me and I am wondering how they can be used.

Can you give me a more detailed event definition of the class?

For instance -

Does VNotificationCenter class stay persistent constantly listening for messages? And if so, what event is fired when a payload is sent to a channel?

Also - can the payload be a function such as refresh?

In principal, notifications are usually set to notify channels whenever a table is updated, and with some can send a notification when a particular operation is carried out such as INSERT, DELETE, UPDATE etc.

Normally a predefined message is sent (defined by the programmer) and this notification can then be acted upon by the client.

The client is then responsible to act upon these notifications.

Lets say 3 people are working on the same database, and one of them updates a particular table, then a notification is sent out and the clients can all refresh there views to reflect this new data.

You can usually setup multiple notifications as well.

Right -

But going back to my question - is the notification class persistent in its connection to the server? Or does it have to poll the server intermittently.

Scott wrote:

Right -

But going back to my question - is the notification class persistent in its connection to the server? Or does it have to poll the server intermittently.

It should be persistent in that once you are listening to a channel it stays open. The kind of thing you could put in its own thread and leave running in the background.

1) You can check example:
V4RB/Examples/VServer/Notifications

2) Yes channel is persistent of course.

What happens internally.

BEFORE you open connection you can say

connection.useSSL = true
connection.useNotifications = true
connection.open()

SSL is not require, just it works in similar way, so I mention this.

Having this info, that you want notifications, VCLIENT connects to VSERVER, and establish 2-ways connections. Also it opens one more internal thread and socket.

article:

http://www.valentina-db.com/docs/dokuwiki/v6/doku.php?id=valentina:articles:vserver_notifications

I looked at the examples - I get the basics.

I may have asked the question incorrectly.

In the examples, the first one uses a pushbutton event to fetch the notification payload.

In the second, it uses a timer control that continually polls the VServer every second for a message (and then acts on it if it receives one).

I was asking when the VNotification class is opened, does the connection remain persistent, and also does it listen itself for traffic on the connection and then fires its own internal event when it receives a payload on the channel. <-- without fetching or polling is what I was asking.

It NOT polls VServer.
It checks queue on client-side only.

Ivan told - there is fixed size queue.
It size is big, but still there is change, that if A LOTS of msgs from Server,
and client do not read queue, you can lost some messages.

I just had a read too. It appears to work slightly different than I expected.

Any client can send a notification, which goes to the server and is then broadcast to other clients via the selected channel.

Is there a way to generate a notification as the result of a database operation i.e

ON INSERT OR UPDATE

SEND "Insert / update completed"

TO CHANNEL

Maybe done by using a trigger ?

Hi Stephen,

Guys, we have made it so far exactly as it is in postgreSQL.

And we yet planning to have internal channels, which will have fixed names, and USERS can subscribe to them, e.g.
- Update of Table Records.

Today, yes you can simulate this using triggers.

To Scott,

events are really Asynch.

Separate socket and thread on client,
Server (!) initiate work on Server -> client direction.

Client App, must choose its own way, depending on programming language,
HOW it will react on events, stored into client-side queue.

Ruslan Zasukhin wrote:

Hi Stephen,

Guys, we have made it so far exactly as it is in postgreSQL.

And we yet planning to have internal channels, which will have fixed names, and USERS can subscribe to them, e.g.
- Update of Table Records.

Today, yes you can simulate this using triggers.

Thanks Ruslan.

Yes - thanks Ruslan.

It's very easy to generate a notification from several sources:


Trigger event
Stored procedures
From a app method, etc.. etc...


And then use them when the client receives them.

I was just asking if the class was like apple's push notification API.

I didn't intend to make this thread so long!

I look forward to further enhancements to the class.

Scott wrote:
I was just asking if the class was like apple's push notification API.
I look forward to further enhancements to the class.

Explain please what you mean

1) I don't know about Apple's push.

2) I do not see what should be enhanced.
postgreSQL have this many years, and this solve task.

I guess, we do not understand yet each other very good.

Ruslan Zasukhin wrote:

Scott wrote:
I was just asking if the class was like apple's push notification API.
I look forward to further enhancements to the class.

Explain please what you mean

1) I don't know about Apple's push.

2) I do not see what should be enhanced.
postgreSQL have this many years, and this solve task.

I guess, we do not understand yet each other very good.

My thought was similar to Scott I think.

It is in a way using push notifications like many others; when we tell the server to do so (Setup and define a channel), we then listen to that channel (Set up a listener).

Instead of us having to poll the server every so many minutes or even seconds, we simply wait for the server to send the message to us. Less network traffic and processing required this way.

In the listener thread we can then act on the message the server has sent to us, and do something like maybe a refresh, and then carry on listening.

This is a good way of doing things.

The internal / fixed channels will enhance this further as well.

Stephan and Scott,

It is in a way using push notifications like many others; when we tell the server to do so (Setup and define a channel), we then listen to that channel (Set up a listener).

Instead of us having to poll the server every so many minutes or even seconds, we simply wait for the server to send the message to us. Less network traffic and processing required this way.

Exactly in this way works Valentina Server.
Exactly in this way works postgreSQL.
I try explain this few times. :-)


You ***NOT*** poll VSERVER, when you just CHECK client-side queue.
IF queue is empty then It is empty. Nothing happens!
There is NO any command to VSERVER by network!

Only when something happens on server side, then server do broadcasting to subscribed N listeners of this channel.
Do I say the same as you?

Once again -- there is no ANY network traffic every second, as you have decide on some reason.

In the listener thread we can then act on the message the server has sent to us, and do something like maybe a refresh, and then carry on listening.

I think problem is that you see that timer, which checks the client-side queue once per second.

Stephan, what problems to make Xojo thread and call GetNotification() there in thread? if you want that.

Xojo have any other way to implement Listener better ?
If yes, please point it to us.

Don't forget that we talking now about construction Xojo <-> plugin.

May be of course exists way to call async Event from plugin to some Xojo Class.Event(),
but as I remember, Xojo have cooperative threads only.

Ruslan Zasukhin wrote:

Stephan and Scott,

It is in a way using push notifications like many others; when we tell the server to do so (Setup and define a channel), we then listen to that channel (Set up a listener).

Instead of us having to poll the server every so many minutes or even seconds, we simply wait for the server to send the message to us. Less network traffic and processing required this way.

Exactly in this way works Valentina Server.
Exactly in this way works postgreSQL.
I try explain this few times. :-)


You ***NOT*** poll VSERVER, when you just CHECK client-side queue.
IF queue is empty then It is empty. Nothing happens!
There is NO any command to VSERVER by network!

Only when something happens on server side, then server do broadcasting to subscribed N listeners of this channel.
Do I say the same as you?

Once again -- there is no ANY network traffic every second, as you have decide on some reason.

In the listener thread we can then act on the message the server has sent to us, and do something like maybe a refresh, and then carry on listening.

I think problem is that you see that timer, which checks the client-side queue once per second.

Stephan, what problems to make Xojo thread and call GetNotification() there in thread? if you want that.

Xojo have any other way to implement Listener better ?
If yes, please point it to us.

Don't forget that we talking now about construction Xojo <-> plugin.

May be of course exists way to call async Event from plugin to some Xojo Class.Event(),
but as I remember, Xojo have cooperative threads only.

Maybe cross wires. I am agreeing with what you are saying, not disagreeing

We monitor the queue, not poll the server. No network congestion. In Xojo we monitor this queue by using a thread running in the background, not a timer.

The thread stays open so we can receive messages one after the other, and not let the messages backup, or we can eventually lose them.

So yes, we are saying the same thing.

Okay, so you can use thread.
We have used in the example timer.
We can add third example with thread