QXmppRosterStorage Class Reference

Storage backend used by QXmppRosterManager to cache the roster between sessions (RFC 6121 §2.6 Roster Versioning). More...

#include <QXmppRosterStorage.h>

Inheritance diagram for QXmppRosterStorage:

Classes
struct	RosterCache
	Snapshot of the persisted roster: server version + items. More...

Public Member Functions
virtual QXmppTask< RosterCache >	load ()=0
	Loads the persisted roster.
virtual QXmppTask< void >	replaceAll (const QString &version, const std::vector< QXmppRosterIq::Item > &items)=0
virtual QXmppTask< void >	upsertItem (const QString &version, const QXmppRosterIq::Item &item)=0
virtual QXmppTask< void >	removeItem (const QString &version, const QString &bareJid)=0
virtual QXmppTask< void >	clear ()=0

Detailed Description

Storage backend used by QXmppRosterManager to cache the roster between sessions (RFC 6121 §2.6 Roster Versioning).

Implementations are responsible for persisting the version string returned by the server together with the current set of roster items. QXmppRosterManager owns a default in-memory implementation (QXmppRosterMemoryStorage); callers that want real persistence implement this interface and pass an instance via QXmppRosterManager::setStorage() before connecting to the server.

All operations are asynchronous so that disk- or network-backed implementations can run off the GUI thread. Each mutating operation carries the new roster version so that the backend can persist the item change and the version atomically.

Ordering

Implementations MUST apply mutations to persistent state in the order they are invoked on a given instance. The returned QXmppTask values may complete in any order — only the visible side effect needs to be ordered. This is because consecutive operations are not commutative: a later upsert for the same JID, or a later version, must not be overwritten by an earlier one landing afterwards. A typical implementation funnels all writes through a single worker / serialized queue.

The storage instance is scoped to a single account. Multi-account applications should either instantiate one storage object per QXmppRosterManager or implement their own JID-scoped backend.

Since

QXmpp 1.16

Out-of-line virtual destructor anchors the vtable in this translation unit.

Member Function Documentation

clear()

virtual QXmppTask< void > QXmppRosterStorage::clear ( )

pure virtual

Wipes all persisted data (items and version). Used on account switch or explicit logout.

removeItem()

virtual QXmppTask< void > QXmppRosterStorage::removeItem ( const QString &  version, const QString &  bareJid  )

pure virtual

Removes the item with the given bare JID (if present) and stores the new version. Called for roster pushes with subscription == Remove.

replaceAll()

virtual QXmppTask< void > QXmppRosterStorage::replaceAll ( const QString &  version, const std::vector< QXmppRosterIq::Item > &  items  )

pure virtual

Replaces every persisted item with the given list and stores the new version. Called when the server returns a full roster snapshot.

upsertItem()

virtual QXmppTask< void > QXmppRosterStorage::upsertItem ( const QString &  version, const QXmppRosterIq::Item &  item  )

pure virtual

Inserts or replaces a single item and stores the new version. Called for roster pushes with subscription != Remove.

---

The documentation for this class was generated from the following files:

• QXmppRosterStorage.h
• QXmppRosterManager.cpp