RE: 3. "Change Reports - ProtocolOps or Primitives"

[Zachary Amsden <zach@xxxxxxxxxxxxx>]

It is a log based implementation, where changes are stored in
separate logs for each *originator*.

*Originator* being an updatable replica with a known replica
identifier.

Thus one supplier may transmit data that gets recorded in
several logs, demultiplexed based on the replicaID.  The logs
are naturally in strictly increasing CSN order because of the
protocol design.

This ordering is sufficient to establish a known update vector
in the case of an interrupted transmission.

Sorry about the terminology confusion.

>You *seem* to be indicating that you have a log based
implementation, in
>which change reports are stored in separate logs for each
originating
>replica
>and that it would therefore be convenient to transmit these
logs in the
>same sequence to consumers. I can understand why separate
logs might be
>used for the local changes and those from each *supplier*,
but I do not
>understand the point of separate logs for each *originator*,
since each
>replication session from a neighbour supplier would be a
mixture of reports
>from
>several originators, who are not necessarily neighbours.