Mercurial > prosody-modules
comparison mod_cloud_notify/business_rules.markdown @ 2609:6ab46ff685d0
mod_cloud_notify: Respect Daniel's business rules and remove endpoints on error
Daniel's business rules can be found here: https://mail.jabber.org/pipermail/standards/2016-February/030925.html
All implementation changes are documented in depth in the file business_rules.markdown
author | tmolitor <thilo@eightysoft.de> |
---|---|
date | Sat, 11 Mar 2017 01:42:45 +0100 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
2608:362ca94192ee | 2609:6ab46ff685d0 |
---|---|
1 XEP-0357 Business rules implementation in prosody | |
2 ================================================= | |
3 | |
4 Daniel proposed some business rules for push notifications [^1] | |
5 This document describes the various implementation details involved in | |
6 implementing these rules in prosody. | |
7 | |
8 Point 3 of Daniel's mail is implemented by setting two attributes | |
9 on the session table when a client enables push for a session: | |
10 | |
11 - push_identifier: this is push_jid .. "<" .. (push_node or "") | |
12 (this value is used as key of the user_push_services table) | |
13 - push_settings: this is a reference to the user_push_services[push_identifier] | |
14 | |
15 | |
16 Point 4 of Daniel's mail contains the actual business rules | |
17 ----------------------------------------------------------- | |
18 | |
19 **a)** | |
20 CSI is honoured in this scenario because messages hold back by csi don't even | |
21 reach the smacks module. mod_smacks has 3 events: | |
22 | |
23 - smacks-ack-delayed: This event is triggered when the client doesn't respond to | |
24 a smacks <r> in a configurable amount of time (default: 60 seconds). | |
25 Mod_cloud_notify reacts on this event and sends out push notifications | |
26 to the push service registered for this session in point 3 (see above) for all | |
27 stanzas in the smacks queue (the queue is given in the event). | |
28 | |
29 - smacks-hibernation-start: This event is triggered when the smacks session | |
30 is put in hibernation state. The event contains the smacks queue, too. | |
31 Mod_cloud_notify uses this event to send push notifications for all | |
32 stanzas not already pushed and installs a "stanzas/out"-filter to | |
33 react on new stanzas coming in while the session is hibernated. | |
34 The push endpoint of the hibernated session is then also notified | |
35 for every new stanza. | |
36 - smacks-hibernation-end: This event is triggered, when the smacks hibernation | |
37 is stopped (the smacks session is resumed) and used by Mod_cloud_notify | |
38 to remove the "stanzas/out"-filter. | |
39 | |
40 **b)** | |
41 Mod_mam already provides an event named "archive-message-added" which is | |
42 triggered every time a stanza is saved into the mam store. | |
43 Mod_cloud_notify uses this event to send out push notifications to all | |
44 push services registered for the user the stanza is for, but *only* | |
45 to those push services not having an active (or smacks hibernated) session. | |
46 Only those stanzas are considered that contain the "for_user" event attribute | |
47 of mod_mam as the user part of the jid. | |
48 This is done to ensure that mam archiving rules are honoured. | |
49 | |
50 **c)** | |
51 The "message/offline/handle"-hook is used to send out push notifications to all | |
52 registered push services belonging to the user the offline stanza is for. | |
53 This was already implemented in the first version of mod_cloud_notify. | |
54 | |
55 | |
56 Some statements to related technologies/XEPs/modules | |
57 ---------------------------------------------------- | |
58 | |
59 - carbons: These are handled as usual and don't interfere with these business rules | |
60 at all. Smacks events are generated for carbon copies if needed and mod_cloud_notify | |
61 uses them to wake up the device in question if needed, as normal stanzas would do, too. | |
62 | |
63 - csi: Csi is honoured also, because every stanza hold back by mod_pump or other csi | |
64 modules is never seen by the smacks module, thus not added to its queue and not | |
65 forwarded to mod_cloud_notify by the smacks events. | |
66 Mod_cloud_notify does only notify devices having no active or smacks hibernated session | |
67 of new mam stored stanzas, so stanzas filtered by csi don't get to mod_cloud_notify | |
68 this way neither. | |
69 | |
70 - other technologies: There shouldn't be any issues with other technologies imho. | |
71 | |
72 [^1]: https://mail.jabber.org/pipermail/standards/2016-February/030925.html |