Helium: Initial proto and Syncable interface definition

blimp/common/proto/helium.proto

+// 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 = "proto3";
+
+option optimize_for = LITE_RUNTIME;
+
+import "blimp_message.proto";
+
+package blimp.helium;
+
+// Vector clock that is used to get the partial order of changes
+// This class is the proto definition of
+// blimp/net/helium/vector_clock.h
+message VectorClock {
+  uint32 local_revision = 1;
+  uint32 remote_revision = 2;
+}
+
+// A FIFO queue of BlimpMessages, for compatibility with features which use
+// the legacy protocol. Should be removed once all features use Helium.
+// This is to allow all messages going through transport 1.0, even though
+// they are still using the old style of messages.
+message LegacyChangeset {

[Kevin M, 2016/09/29 20:01:16]

I think we should cross this particular bridge when we get to it - we don't know
what the exact shape and requirements of this object will be.

What about a TestChangeset?

[scf, 2016/09/29 23:13:38]

Done.

+  repeated BlimpMessage messages = 1;
+}
+
+// A "union" of the allowed types that are going to be serialized. There will
+// be one for each feature that requires serialization.

[Kevin M, 2016/09/29 20:01:16]

feature => Helium Object?

[scf, 2016/09/29 23:13:38]

Done.

+// For example: GeoLocation, EngineSettings, etc.
+message Changeset {
+  oneof data {
+    // Support for legacy style of messages
+    LegacyChangeset legacy = 1;
+  };
+}
+
+// A message encapsulates the actual Changeset with the identifier of the
+// object and the timestamp of the checkpoint.
+message Message {

[Kevin M, 2016/09/29 20:01:16]

"Message" is too overloaded - HeliumMessage?

[scf, 2016/09/29 23:13:38]

Done.

+  // 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).
+  VectorClock from = 1;

[Kevin M, 2016/09/29 20:01:16]

Use blank lines to separate commented field blocks.

[scf, 2016/09/29 23:13:38]

Done.

+  // 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.
+  VectorClock to = 2;
+  // Identifies the Object to which this changeset applies.
+  uint32 object_id = 3;
+  // The changeset that contain the actual changes
+  Changeset change = 4;
+}