search

EGreg / Platform-history

The Qbix Platform for powering Social Applications
http://qbix.com/platform
GNU Affero General Public License v3.0
21 stars 5 forks source link

Implement delivery of notifications #9

Open EGreg opened 10 years ago

EGreg commented 10 years ago

Currently, the notifications are delivered to email addresses and mobile phone numbers, but not all the functionality is implemented.

Please refactor the code in plugins/Streams/classes/Streams.js and plugins/Streams/classes/Streams/Stream.js to be cleaner and match the PHP code in functionality, such as stream.subscribe() and stream.join().

The Node.js processes should be designed to work after a crash and subsequent restart, maintaining caches such as Participant.get.cache. Because of this design requirement, many objects (such as Stream.Subscription and Stream.Rule rows) aren't cached but repeatedly fetched from the database when needed. To cache them, we would need to make sure that a) only PHP updates those rows, and b) PHP will call Q_Utils::sendToNode to hit some newly implemented Streams.onEvent('post') event handler in Streams.js.

Add a new method for deliver besides the mobile and email ones, called url. The value would be a URL to POST structured notification data to. The handler for this URL might be in PHP or it might be in Node.js . Better to have it in Node.js because, if everything is running on the same machine and Node.js is issuing these requests, then we don't want 500 concurrent requests being handled by PHP. Moreover, if the URL is discovered to be internally handled by the same Node.js script that "delivers" the notification, the whole HTTP transport can be avoided and the handler can be called internally.

Finally, make a new issue for respecting the fields in streams_subscription and then in streams_rule. Fields such as subscription: untilTime, filter, duration; and rule: filter, deliver, relevance

EGreg commented 10 years ago

And also in that issue describe mechanism for handling notification rules.

For example, Streams/invited should have a rule handler that runs before the others and checks Streams.Invite table for invite with same token, and passes it ro the rule handler so it can inspect the "requested" state before making its decision.

Make another issue for handling Streams/authenticated/$App streams which would then update contacts list on that baseUrl, in case you want to join it. Use a regular Users/contacts tool to display these contacts filtered to who is on that particular baseUrl.

EGreg commented 10 years ago

And also in that issue describe mechanism for handling notification rules.

For example, Streams/invited should have a rule handler that runs before the others and checks Streams.Invite table for invite with same token, and passes it ro the rule handler so it can inspect the "requested" state before making its decision.

Make another issue for handling Streams/authenticated/$App streams which would then update contacts list on that baseUrl, in case you want to join it. Use a regular Users/contacts tool to display these contacts filtered to who is on that particular baseUrl.