pub struct Message {
pub heads: Vec<ChangeHash>,
pub need: Vec<ChangeHash>,
pub have: Vec<Have>,
pub changes: ChunkList,
pub supported_capabilities: Option<Vec<Capability>>,
pub version: MessageVersion,
}Expand description
The sync message to be sent.
Notes about encoding
There are two versions of the sync message, V1 and V2. The V1 message is the original message which automerge shipped with and V2 is an extension which allows for encoding the changes as either a list of changes or as a compressed document format. This makes syncing up for the first time faster.
Encoding this in a backwards compatible way is a bit tricky. The wire format of the v1 message
didn’t allow for any forwards compatible changes. In order to accomodate this the first message
a peer sends is a V1 message with a length previxed Vec<Capability> appended to it. For old
implementations this appended data is just ignored but new implementations read it and store
the advertised capabilities on the sync state. This allows new implementations to discover if
the remote peer supports the V2 message format (the Capability::MessageV2 capability) and if
so send a V2 message.
Fields§
§heads: Vec<ChangeHash>The heads of the sender.
need: Vec<ChangeHash>The hashes of any changes that are being explicitly requested from the recipient.
have: Vec<Have>A summary of the changes that the sender already has.
changes: ChunkListThe changes for the recipient to apply.
This is a Vec of bytes which should be passed to Automerge::load_incremental. The reason
it is a Vec<Vec<u8>> and not a Vec<u8> is that the V1 message format is a sequence of
change chunks, each of which is length delimited. The V2 message format is a single length
delimited chunk but we nest it inside a Vec for backwards compatibility.
supported_capabilities: Option<Vec<Capability>>The capabilities the sender supports
version: MessageVersionWhat version to encode this message as