sync: Report GetUpdate triggers to the server

sync/protocol/sync.proto

 // Copyright (c) 2012 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.
 //
 // Sync protocol for communication between sync client and server.
 
 // Update proto_value_conversions{.h,.cc,_unittest.cc} if you change
 // any fields in this file.
 
 syntax = "proto2";
@@ skipping 383 matching lines @@
   // make commit-time decisions about how to process datatypes that might
   // involve server-side interaction, and e.g require explicit user intent for
   // syncing a particular data type regardless of whether a commit for that
   // datatype is currently being sent up.
   optional ClientConfigParams config_params = 4;
 };
 
 // This message communicates additional per-type information related to
 // requests with origin GU_TRIGGER.  This message is not relevant when any
 // other origin value is used.
-// Introduced in M28.
+// Introduced in M29.
 message GetUpdateTriggers {
   // An opaque-to-the-client string of bytes, received through a notification,
   // that the server may interpret as a hint about the location of the latest
   // version of the data for this type.
   //
   // Note that this will eventually replace the 'optional' field of the same
   // name defined in the progress marker, but the client and server should
   // support both until it's safe to deprecate the old one.
   //
-  // This field was introduced in M28.
+  // This field was introduced in M29.
   repeated string notification_hint = 1;
 
   // This flag is set if the client was forced to drop hints because the number
   // of queued hints exceeded its limit.  The oldest hints will be discarded
-  // first.  Introduced in M28.
+  // first.  Introduced in M29.
   optional bool client_dropped_hints = 2;
 
   // This flag is set if the invalidation server reports that it may have
   // dropped some invalidations at some point.  The client will also drop any
   // locally cached hints that are older than the server-did-drop notification.
   //
   // TODO(sync): Determine the format for this.
   //
   // optional bool server_dropped_hints = 6;
 
   // This flag is set when the client suspects that its list of invalidation
   // hints may be incomplete.  This may be the case if:
   // - The client is syncing for the first time.
   // - The client has just restarted and it was unable to keep track of
   //   invalidations that were received prior to the restart.
   // - The client's connection to the invalidation server is currently or
   //   was recently broken.
   //
   // It's difficult to provide more details here.  This is implemented by
   // setting the flag to false whenever anything that might adversely affect
   // notifications happens (eg. a crash, restart on a platform that doesn't
   // support invalidation ack-tracking, transient invalidation error) and is
   // unset only after we've experienced one successful sync cycle while
   // notifications were enabled.
   //
-  // This flag was introduced in M28.
+  // This flag was introduced in M29.
   optional bool invalidations_out_of_sync = 3;
 
   // This counts the number of times the syncer has been asked to commit
   // changes for this type since the last successful sync cycle.  The number of
   // nudges may not be related to the actual number of items modified.  It
   // often correlates with the number of user actions, but that's not always
   // the case.
-  // Introduced in M28.
+  // Introduced in M29.
   optional int64 local_modification_nudges = 4;
 
   // This counts the number of times the syncer has been explicitly asked to
   // fetch updates for this type since the last successful sync cycle.  These
   // explicit refresh requests should be relatively rare on most platforms, and
   // associated with user actions.  For example, at the time of this writing
   // the most common (only?) source of refresh requests is when a user opens
   // the new tab page on a platform that does not support sessions
   // invalidations.
-  // Introduced in M28.
+  // Introduced in M29.
   optional int64 datatype_refresh_nudges = 5;
 }
 
 message DataTypeProgressMarker {
   // An integer identifying the data type whose progress is tracked by this
   // marker.  The legitimate values of this field correspond to the protobuf
   // field numbers of all EntitySpecifics fields supported by the server.
   // These values are externally declared in per-datatype .proto files.
   optional int32 data_type_id = 1;
 
@@ skipping 24 matching lines @@
   // progress tracking mechanism, but which wish to switch over to the opaque
   // token mechanism can set this field in a GetUpdatesMessage.  The server
   // will perform a get updates operation as normal from the indicated
   // timestamp, and return only an opaque progress token.
   optional int64 timestamp_token_for_migration = 3;
 
   // An opaque-to-the-client string of bytes, received through a notification,
   // that the server may interpret as a hint about the location of the latest
   // version of the data for this type.
   //
-  // Deprecated in M28.  We should use the repeated field version in the
+  // Deprecated in M29.  We should use the repeated field version in the
   // PerClientTypeState instead.
   optional string notification_hint = 4;
 
   // This field will be included only in GetUpdates with origin GU_TRIGGER.
   optional GetUpdateTriggers get_update_triggers = 5;
 }
 
 message GetUpdatesMessage {
   // Indicates the client's current progress in downloading updates.  A
   // from_timestamp value of zero means that the client is requesting a first-
   // time sync.  After that point, clients should fill in this value with the
   // value returned in the last-seen GetUpdatesResponse.new_timestamp.
   //
   // from_timestamp has been deprecated; clients should use
   // |from_progress_marker| instead, which allows more flexibility.
   optional int64 from_timestamp = 1;
 
   // Indicates the reason for the GetUpdatesMessage.
-  // Deprecated in M28.  We should eventually rely on GetUpdatesOrigin instead.
+  // Deprecated in M29.  We should eventually rely on GetUpdatesOrigin instead.
   // Newer clients will support both systems during the transition period.
   optional GetUpdatesCallerInfo caller_info = 2;
 
   // Indicates whether related folders should be fetched.
   optional bool fetch_folders = 3 [default = true];
 
   // The presence of an individual EntitySpecifics field indicates that the
   // client requests sync object types associated with that field.  This
   // determination depends only on the presence of the field, not its
   // contents -- thus clients should send empty messages as the field value.
@@ skipping 35 matching lines @@
   // The allowed frequency for requesting encryption keys is much lower than
   // other datatypes, so repeated usage will likely result in throttling.
   optional bool need_encryption_key = 8 [default = false];
 
   // Whether to create the mobile bookmarks folder if it's not
   // already created.  Should be set to true only by mobile clients.
   optional bool create_mobile_bookmarks_folder = 1000 [default = false];
 
   // This value is an udpated version of the GetUpdatesCallerInfo's
   // GetUpdatesSource.  It describes the reason for the GetUpdate request.
-  // Introduced in M28.
+  // Introduced in M29.
   optional SyncEnums.GetUpdatesOrigin get_updates_origin = 9;
 };
 
 message AuthenticateMessage {
   required string auth_token = 1;
 };
 
 // The client must preserve, store, and resend the chip bag with
 // every request.  The server depends on the chip bag in order
 // to precisely choreograph a client-server state machines.
@@ skipping 261 matching lines @@
     // is absent then the whole client (all datatypes) is throttled.
     repeated int32 error_data_type_ids = 5;
   }
   optional Error error = 13;
 
   // The new per-client state for this client. If set, should be persisted and
   // sent with any subsequent ClientToServerMessages.
   optional ChipBag new_bag_of_chips = 14;
 };