Wavelet Update Operation

The best way to go into the architecture of the WSP implementation that I am working on is to show each of the messages that are part of the wave federation protocol and how they interact with the platform. The first message that I will be going into detail on is the wavelet update operation.

The update element is contained within a XMPP iq stanza of type set with a unique id. The update element has the following structure:
Where boxed nodes are elements and none boxed nodes are attributes. Note: the hashed-version element under the delta element has the same attributes as the hashed-version under the applied delta.

Each update message contains at least one wavelet update and may contain more, this would be useful when multiple conversations are being held between participants on the same two wave servers. The wavelet that the update is being performed against is specified by the wavelet name attribute.

Each wavelet update then has zero or more applied delta's these contain a delta that was successfully applied by the authoritative wavelet server to the given wavelet. This has attributes saying how many operations were performed, and when the delta was applied. Also provided within the applied delta are a hashed version specifying the version after the delta was applied and the signature of the delta authors domain.

The delta operation has just the single author attribute. The delta contains a set of operations to be performed on the wavelet (discussed in my Wavelet Operations post), as well as a hashed version specifying the version that the delta was intended to be applied against. This may differ from the applied delta's hashed version if someone is concurrently editing the wavelet.

The last part is the optional commit notice element. This is a variant of the hashed version element that specifies the maximum currently applied delta's version. This is used primarily when reconnecting to a wave server that has been down for a period, where the authoritative wave server will tell the other wave server the current version and expect it to request the applied delta's through a history request.

In processing an update the following sequence is followed (at a high level):
The update is sent from the federation host to the federation remote which splits it into wavelet updates. The controller is then called with each wavelet update. The controller loads the given wavelet, then for each applied delta an operation is created to apply the delta. The delta is then applied to the wavelet, and the wavelet is stored back to the data store.

Next post will be covering the history request / history response messages (included in there will be how the commit notice in the wavelet update comes into play.