Warlock: Message filters #29

New issue

Closed

opened 2014-04-29 03:22:02 +00:00 by jamie · 2 comments

jamie commented

2014-04-29 03:22:02 +00:00

(Migrated from git.hazaar.io)

I've come across a bit of a problem with the warlock real-time messaging sub-system in regards to the particular way that I am trying to use it.

The situation is, clients listen for a 'notification'. When a notification is sent a Warlock trigger event is fired off with the content of the notification. The client will then display this notification.

The problem I have is that all clients listen for the same event trigger name "uplink_notification", but in certain circumstances I only want the message to go to certain clients and other clients should ignore it. There could be a work around where notifications are split into types and the client listens for multiple events based on each type they want to see, but this sounds a bit resource intensive and just a bit silly.

To that end, I would like to implement message filters so that messages that contain (or don't contain) certain data can be ignored. This will happen at the server level so that these filtered messages will not cause the usual process and re-listen connection routine.

How I see this working:

Client issues are standard 'listen' call. This time with an extra parameter, probably as a specially formatted object containing the filter definition.
The trigger is fired as normal.
Warlock processes the trigger as normal but instead of just sending the message to all connected clients it checks each client connection for a filter. The filter is then processed against the message and sent only if it matches.

I've come across a bit of a problem with the warlock real-time messaging sub-system in regards to the particular way that I am trying to use it. The situation is, clients listen for a 'notification'. When a notification is sent a Warlock trigger event is fired off with the content of the notification. The client will then display this notification. The problem I have is that all clients listen for the same event trigger name "uplink_notification", but in certain circumstances I only want the message to go to certain clients and other clients should ignore it. There could be a work around where notifications are split into types and the client listens for multiple events based on each type they want to see, but this sounds a bit resource intensive and just a bit silly. To that end, I would like to implement message filters so that messages that contain (or don't contain) certain data can be ignored. This will happen at the server level so that these filtered messages will not cause the usual process and re-listen connection routine. How I see this working: 1. Client issues are standard 'listen' call. This time with an extra parameter, probably as a specially formatted object containing the filter definition. 2. The trigger is fired as normal. 3. Warlock processes the trigger as normal but instead of just sending the message to all connected clients it checks each client connection for a filter. The filter is then processed against the message and sent only if it matches.

jamie commented

2014-04-30 05:21:10 +00:00

(Migrated from git.hazaar.io)

Status changed to closed by commit 0e35a9

jamie commented

2015-12-03 02:27:11 +00:00

(Migrated from git.hazaar.io)

mentioned in commit 0e35a9fc06

mentioned in commit 0e35a9fc06d3a6fbdf16a909cf81765bbe117e20

Commenting is not possible because the repository is archived.