Initial definition of HeliumSyncManager and SyncRegistration objects.

blimp/common/proto/helium.proto

Index: blimp/common/proto/helium.proto
diff --git a/blimp/common/proto/helium.proto b/blimp/common/proto/helium.proto
new file mode 100644
index 0000000000000000000000000000000000000000..e790f5c2214f65ecab2a9d3ae03879ae0ea230ff
--- /dev/null
+++ b/blimp/common/proto/helium.proto
@@ -0,0 +1,54 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+//
+// Over-the-wire message definitions used for the Helium
+// synchronization protocol.
+
+syntax = "proto2";

[scf, 2016/09/28 17:17:59]

use proto3 as you describe no?

+
+option optimize_for = LITE_RUNTIME;
+
+import "blimp_message.proto";
+
+package blimp.proto;

[scf, 2016/09/28 17:18:00]

i've noticed other proto files use "package blimp"

+
+// A FIFO queue of BlimpMessages, for compatibility with features which use
+// the legacy protocol. Should be removed once all features use Helium.
+message TransitionalChangeset {

[scf, 2016/09/28 17:17:59]

rename it to LegacyChangeset? 

[perumaal, 2016/09/28 23:31:30]

I am confused. Wouldn't you want to wrap a HeliumMessage inside a BlimpMessage
to begin with?
Otherwise, how would this even work with HeliumTransport on top of
BlimpTransport?

i.e.
BlimpMessage {
oneof {
  InputFeature;
  NavigationFeature;
...
  HeliumFeature; // Wrap Helium message here.
}
}

+  repeated BlimpMessage messages = 1;
+}
+
+message HeliumRevision {

[scf, 2016/09/28 17:18:00]

Call it HeliumVectorClock so that it matches the c++ impl?

+  optional int32 local_revision = 1;

[scf, 2016/09/28 17:18:00]

uint32 so that matches the VectorClock

+  optional int32 remote_revision = 2;
+}
+
+message HeliumChangeset {
+  oneof changes { TransitionalChangeset transitional = 1; }
+}
+
+message HeliumMessage {
+  // Identifies the local revision that this changeset applies to (relative
+  // to the sender), and the remote revision that the local side most recently
+  // received (i.e. an ACK, in effect).
+  // Note that the local revision can usually be inferred rather than actually
+  // sent on the wire. Similarly the remote revision may be omitted if it
+  // hasn’t changed since the last changeset was sent.
+  optional HeliumRevision reference_revision = 1;

[scf, 2016/09/28 17:17:59]

i like calling from/to as it matches the sync_manager definition. but not
feeling super strong about this

+
+  // Provides the local view of the vector-clock following application of
+  // the changeset. This allows a single changeset to collate changes across
+  // several revisions, following a break in connectivity, rather than simply
+  // re-transmitting the lost changesets.
+  // Note that this can usually be inferred rather than send on-the-wire.
+  optional HeliumRevision changeset_revision = 2;
+
+  // Identifies the Object to which this changeset applies.
+  // Note that this may be omitted if the previous message on this Stream
+  // was for the same Object.
+  optional int32 object_id = 3;

[scf, 2016/09/28 17:17:59]

change to uint32 for consistency with HeliumObjectId?

+
+  // Changeset to be applied to the relevant Object.
+  optional HeliumChangeset changeset = 4;
+}