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