This module is still in development, see #127. XEP-0163 XEP-0060
Assumptions
- Only one item per node ever needs to be persisted
- Subscribers only really need to request the current node...
- A full publish-subscribe service is not required and could be better implemented as a separate service
- Explicit subscribe/unsubscribe requests will be rejected
- "open" access requires knowing about entities that have sent us presence
- "presence" access is easily done
- "roster" access can use storage (cached at runtime?)
- "whitelist" access can use storage (cached at runtime?)
- Explicit subscribe/unsubscribe requests will be rejected
Publish-Subscribe features
This list is likely to be incomplete.
auto-subscribe/filtered-notifications
Use current presence data and mod_caps to determine what to send resources that we know are online when a new item is published
auto-create/create-nodes
Create blank node entry in pep-items
publish
Store + deliver/notify
delete-nodes
Delete node entry and access list data
retrieve-items
Check access and return item if it exists
config-node
Configures node access model
Storage
pep-items
| collection-owner | text | JID |
| object-sequence | bigint | ? |
| node | text | PEP node |
| access | text | open/presence/roster/whitelist |
| item | text | PEP item (xml) |
PK: collection-owner + node
pep-whitelist
| collection-owner | text | JID |
| object-sequence | bigint | ? |
| node | text | PEP node |
| jid | text | Whitelisted JID |
PK: collection-owner + node + jid
pep-roster
| collection-owner | text | JID |
| object-sequence | bigint | ? |
| node | text | PEP node |
| group | text | Allowed group |
PK: collection-owner + node + group
Notes
Accessing other modules data (presence information, roster) could be problematic, as there is no defined way to do this yet. There is a hack to find one SX module by another, but it's not very pretty.
