The specifications published on http://waveprotocol.org represent the intended implementation target for all the code hosted here. As of today (Oct 2009) there are differences between what is documented and what is actually implemented in the code. In the long term the two will converge, but for now this page will document differences between the specifications and the code as it works today.
Section 8.4.2 of the Wave Conversation Model documents a contributor element.
The contributor element for blips is not used and a server should never add any contributor elements to a blip as such ops will be rejected. The list of contributors to a blip is calculated by recording all the authors of operations to that blip.
Section 11 of the Wave Conversation Model documents mechanisms for changing the document structure of a conversation. That entire section should be ignored and the mechanisms described below should be used instead.
In the mechanisms below, each bulleted point should be performed in a single (hence atomic) operation submitted to the wave server.
The interim model requires signaling the addition of a new blip before writing content into it. This signal takes the form of an empty document operation (a document operation with no components) against the to-be-created blip.
Thus the mechanism for adding a blip is:
The mechanism for adding a thread in reply to a blip is:
A blip should immediately be added to the thread. Empty thread elements are candidates for removal.
An inline thread must always be anchored to a specific element in the replied-to blip. Thus the mechanism for adding an inline reply to a blip is:
Deleting a blip with no replies¶
A blip with no replies is removed from the conversation manifest. The mechanism for deleting a blip is:
The Google Wave client implements deletion by recursively removing all inline replies to the deleted blip but leaving non-inline replies. The surviving replies remain as children of a blip which is logically deleted, but still present in the conversation manifest to serve as a parent to those replies.
Federated clients may implement deletion similarly, or may choose to delete non-inline replies as well, similar to the first case below.
The mechanism for deleting a blip with inline replies but no non-inline replies is:
The mechanism for deleting a blip with non-inline replies is:
If the remaining replies to the deleted blip are removed, the empty deleted blip element should be removed from the conversation manifest.