-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The MIRROR Persistence Service is registered as component of the XMPP domain and therefore acts on the same level as the MIRROR Spaces Service. Whilst the Spaces Service is mandatory within the MIRROR Spaces Framework (MSF), the Persistence Service is optional.
In its current implementation, the service is realized as plug-in for the Openfire XMPP server.
Note: Only instances of MIRROR data models are persisted, i.e., data objects with a namespace
mirror:*.
The setup process is described in the README file.
Note: More details on XMPP communication in general and the space configuration in particular can be found in the documentation of the MIRROR Spaces Service.
The space configuration has been slightly modified to support the persistence service. The spaces#persistent field now has three valid options:
-
falseto disable persistence of data objects published on the pubsub node of the space. -
trueto enable persistence without any limitations to the lifetime of published data objects. Data objects can still be deleted manually. - A XSD duration string which specifies the lifetime of all subsequently published data objects. Expired data objects will be purged automatically.
The following snippet of a space configuration requests sets the persistence duration to one day (P1D).
[…]
<configure>
<x xmlns="jabber:x:data" type="submit">
<field var="FORM_TYPE" type="hidden">
<value>
urn:xmpp:spaces:config
</value>
</field>
<field var="spaces#type">
<value>team</value>
</field>
<field var="spaces#persistent">
<value>P1D</value>
</field>
<field var="spaces#name">
<value>TOP team</value>
</field>
<field var="spaces#members">
<value>john.doe@mydomain</value>
<value>jane.doe@mydomain</value>
</field>
<field var="spaces#moderators">
<value>john.doe@mydomain</value>
</field>
</x>
</configure>
[…]If a space is configured to be persisted, an additional space channel is available representing Persistence Service XMPP component:
[…]
<spaces xmlns="urn:xmpp:spaces">
<channels space="alice">
[…]
<channel type="persistence">
<property key="jid">persistence.mirror-demo.eu</property>
</channel>
[…]
</channels>
</spaces>
[…]Queries are performed by sending an IQ stanza of type GET to the Persistence Service component. The IQ contains a single child named query with the namespace urn:xmpp:spaces:persistence.
Each query has the following structure:
<query xmlns="urn:xmpp:spaces:persistence">
<!-- space or id information -->
<!-- filters (optional) -->
</query>As response either an IQ of type RESULT is sent to the client, containing a list of data objects (which may be empty), or IQ of type ERROR.
<query xmlns="urn:xmpp:spaces:persistence">
<result>
<ping xmlns="mirror:application:ping:ping"
publisher="alice@localhost/persistenceTest" modelVersion="1.0" cdmVersion="1.0" id="41692734-a6a2-46c2-89eb-ea3644272a16" timestamp="2013-04-08T16:06:58.557+02:00" schemaLocation="mirror:application:ping:ping http://data.mirror-demo.eu/application/ping/ping-1.0.xsd">
<content>Sample content.</content>
</ping>
<ping xmlns="mirror:application:ping:ping" publisher="alice@localhost/persistenceTest" modelVersion="1.0" cdmVersion="1.0" id="d49996ba-338d-4695-adcb-65a068f4555c" timestamp="2013-04-08T16:02:40.730+02:00" schemaLocation="mirror:application:ping:ping http://data.mirror-demo.eu/application/ping/ping-1.0.xsd" />
</result>
</query>Data objects can be queried either by space or by data object identifiers. For both options commands are available to address multiple entities.
If the ID for a data object is known, e.g. as reference, object can be retrieved using the following query:
<query xmlns="urn:xmpp:spaces:persistence">
<object id="41692734-a6a2-46c2-89eb-ea3644272a16" />
</query>To request multiple objects in a single query, you can place multiple <object> elements within an objects tag:
<query xmlns="urn:xmpp:spaces:persistence">
<objects>
<object id="41692734-a6a2-46c2-89eb-ea3644272a16" />
<object id="d49996ba-338d-4695-adcb-65a068f4555c" />
</objects>
</query>Queries by ID are performed over all spaces persisted by the service. The MIRROR Spaces Access Model (MSAM) is applied to all queries. If the requesting user is not allowed to access one or more of the requested data objects, i.e., one of the spaces the data objects are published on, the respective error is returned.
It is also possible to retrieve all data objects stored for a space or even multiple spaces.
<query xmlns="urn:xmpp:spaces:persistence">
<objectsForSpace id="team#123" />
</query><query xmlns="urn:xmpp:spaces:persistence">
<objectsForSpaces>
<space id="orga#5" />
<space id="team#123" />
</objectsForSpaces>
</query>Filters can be applied to all queries to restrictthe result to data objects with specific properties. They are specified within the query in a filters tag right after the entity selection, e.g.:
<query xmlns="urn:xmpp:spaces:persistence">
<objectsForSpaces>
<space id="orga#5" />
<space id="team#123" />
</objectsForSpaces>
<filters>
<period from="2013-04-09T10:30:00+01:00" to="2013-04-09T11:00:00+01:00" />
</filters>
</query>It is possible to list multiple filters for further restriction. A list of supported filters is available here.
Data objects can be deleted manually by sending an IQ SET request to the Persistence Service component:
<delete xmlns="urn:xmpp:spaces:persistence">
<object id="d49996ba-338d-4695-adcb-65a068f4555c" />
</delete><delete xmlns="urn:xmpp:spaces:persistence">
<objects>
<object id="41692734-a6a2-46c2-89eb-ea3644272a16" />
<object id="d49996ba-338d-4695-adcb-65a068f4555c" />
</objects>
</delete>The lifetime of a data object is usually handled by the service itself. It is possible to break object dependencies by deleting objects manually. By default, this operation is only permitted for space moderators. Current versions of the service can be configured to permit data object deletion also for data object publishers.