• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright (c) 2012 The Chromium Authors. All rights reserved.
2// Use of this source code is governed by a BSD-style license that can be
3// found in the LICENSE file.
4//
5// Sync protocol for communication between sync client and server.
6
7// Update proto_value_conversions{.h,.cc,_unittest.cc} if you change
8// any fields in this file.
9
10syntax = "proto2";
11
12option optimize_for = LITE_RUNTIME;
13option retain_unknown_fields = true;
14
15package sync_pb;
16
17import "app_list_specifics.proto";
18import "app_notification_specifics.proto";
19import "app_setting_specifics.proto";
20import "app_specifics.proto";
21import "article_specifics.proto";
22import "attachments.proto";
23import "autofill_specifics.proto";
24import "bookmark_specifics.proto";
25import "client_commands.proto";
26import "client_debug_info.proto";
27import "device_info_specifics.proto";
28import "dictionary_specifics.proto";
29import "encryption.proto";
30import "experiments_specifics.proto";
31import "extension_setting_specifics.proto";
32import "extension_specifics.proto";
33import "favicon_image_specifics.proto";
34import "favicon_tracking_specifics.proto";
35import "get_updates_caller_info.proto";
36import "history_delete_directive_specifics.proto";
37import "nigori_specifics.proto";
38import "managed_user_setting_specifics.proto";
39import "managed_user_shared_setting_specifics.proto";
40import "managed_user_specifics.proto";
41import "password_specifics.proto";
42import "preference_specifics.proto";
43import "priority_preference_specifics.proto";
44import "search_engine_specifics.proto";
45import "session_specifics.proto";
46import "sync_enums.proto";
47import "synced_notification_app_info_specifics.proto";
48import "synced_notification_specifics.proto";
49import "theme_specifics.proto";
50import "typed_url_specifics.proto";
51import "unique_position.proto";
52
53// Used for inspecting how long we spent performing operations in different
54// backends. All times must be in millis.
55message ProfilingData {
56  optional int64 meta_data_write_time = 1;
57  optional int64 file_data_write_time = 2;
58  optional int64 user_lookup_time = 3;
59  optional int64 meta_data_read_time = 4;
60  optional int64 file_data_read_time = 5;
61  optional int64 total_request_time = 6;
62}
63
64message EntitySpecifics {
65  // If a datatype is encrypted, this field will contain the encrypted
66  // original EntitySpecifics. The extension for the datatype will continue
67  // to exist, but contain only the default values.
68  // Note that currently passwords employ their own legacy encryption scheme and
69  // do not use this field.
70  optional EncryptedData encrypted = 1;
71
72  // To add new datatype-specific fields to the protocol, extend
73  // EntitySpecifics.  First, pick a non-colliding tag number by
74  // picking a revision number of one of your past commits
75  // to src.chromium.org.  Then, in a different protocol buffer
76  // definition, define your message type, and add an optional field
77  // to the list below using the unique tag value you selected.
78  //
79  //  optional MyDatatypeSpecifics my_datatype = 32222;
80  //
81  // where:
82  //   - 32222 is the non-colliding tag number you picked earlier.
83  //   - MyDatatypeSpecifics is the type (probably a message type defined
84  //     in your new .proto file) that you want to associate with each
85  //     object of the new datatype.
86  //   - my_datatype is the field identifier you'll use to access the
87  //     datatype specifics from the code.
88  //
89  // Server implementations are obligated to preserve the contents of
90  // EntitySpecifics when it contains unrecognized fields.  In this
91  // way, it is possible to add new datatype fields without having
92  // to update the server.
93  //
94  // Note: The tag selection process is based on legacy versions of the
95  // protocol which used protobuf extensions. We have kept the process
96  // consistent as the old values cannot change.  The 5+ digit nature of the
97  // tags also makes them recognizable (individually and collectively) from
98  // noise in logs and debugging contexts, and creating a divergent subset of
99  // tags would only make things a bit more confusing.
100
101  optional AutofillSpecifics autofill = 31729;
102  optional BookmarkSpecifics bookmark = 32904;
103  optional PreferenceSpecifics preference = 37702;
104  optional TypedUrlSpecifics typed_url = 40781;
105  optional ThemeSpecifics theme = 41210;
106  optional AppNotification app_notification = 45184;
107  optional PasswordSpecifics password = 45873;
108  optional NigoriSpecifics nigori = 47745;
109  optional ExtensionSpecifics extension = 48119;
110  optional AppSpecifics app = 48364;
111  optional SessionSpecifics session = 50119;
112  optional AutofillProfileSpecifics autofill_profile = 63951;
113  optional SearchEngineSpecifics search_engine = 88610;
114  optional ExtensionSettingSpecifics extension_setting = 96159;
115  optional AppSettingSpecifics app_setting = 103656;
116  optional HistoryDeleteDirectiveSpecifics history_delete_directive = 150251;
117  optional SyncedNotificationSpecifics synced_notification = 153108;
118  optional SyncedNotificationAppInfoSpecifics synced_notification_app_info =
119      235816;
120  optional DeviceInfoSpecifics device_info = 154522;
121  optional ExperimentsSpecifics experiments = 161496;
122  optional PriorityPreferenceSpecifics priority_preference = 163425;
123  optional DictionarySpecifics dictionary = 170540;
124  optional FaviconTrackingSpecifics favicon_tracking = 181534;
125  optional FaviconImageSpecifics favicon_image = 182019;
126  optional ManagedUserSettingSpecifics managed_user_setting = 186662;
127  optional ManagedUserSpecifics managed_user = 194582;
128  optional ManagedUserSharedSettingSpecifics managed_user_shared_setting =
129      202026;
130  optional ArticleSpecifics article = 223759;
131  optional AppListSpecifics app_list = 229170;
132}
133
134message SyncEntity {
135  // This item's identifier.  In a commit of a new item, this will be a
136  // client-generated ID.  If the commit succeeds, the server will generate
137  // a globally unique ID and return it to the committing client in the
138  // CommitResponse.EntryResponse.  In the context of a GetUpdatesResponse,
139  // |id_string| is always the server generated ID.  The original
140  // client-generated ID is preserved in the |originator_client_id| field.
141  // Present in both GetUpdatesResponse and CommitMessage.
142  optional string id_string = 1;
143
144  // An id referencing this item's parent in the hierarchy.  In a
145  // CommitMessage, it is accepted for this to be a client-generated temporary
146  // ID if there was a new created item with that ID appearing earlier
147  // in the message.  In all other situations, it is a server ID.
148  // Present in both GetUpdatesResponse and CommitMessage.
149  optional string parent_id_string = 2;
150
151  // old_parent_id is only set in commits and indicates the old server
152  // parent(s) to remove. When omitted, the old parent is the same as
153  // the new.
154  // Present only in CommitMessage.
155  optional string old_parent_id = 3;
156
157  // The version of this item -- a monotonically increasing value that is
158  // maintained by for each item.  If zero in a CommitMessage, the server
159  // will interpret this entity as a newly-created item and generate a
160  // new server ID and an initial version number.  If nonzero in a
161  // CommitMessage, this item is treated as an update to an existing item, and
162  // the server will use |id_string| to locate the item.  Then, if the item's
163  // current version on the server does not match |version|, the commit will
164  // fail for that item.  The server will not update it, and will return
165  // a result code of CONFLICT.  In a GetUpdatesResponse, |version| is
166  // always positive and indentifies the revision of the item data being sent
167  // to the client.
168  // Present in both GetUpdatesResponse and CommitMessage.
169  required int64 version = 4;
170
171  // Last modification time (in java time milliseconds)
172  // Present in both GetUpdatesResponse and CommitMessage.
173  optional int64 mtime = 5;
174
175  // Creation time.
176  // Present in both GetUpdatesResponse and CommitMessage.
177  optional int64 ctime = 6;
178
179  // The name of this item.
180  // Historical note:
181  //   Since November 2010, this value is no different from non_unique_name.
182  //   Before then, server implementations would maintain a unique-within-parent
183  //   value separate from its base, "non-unique" value.  Clients had not
184  //   depended on the uniqueness of the property since November 2009; it was
185  //   removed from Chromium by http://codereview.chromium.org/371029 .
186  // Present in both GetUpdatesResponse and CommitMessage.
187  required string name = 7;
188
189  // The name of this item.  Same as |name|.
190  // |non_unique_name| should take precedence over the |name| value if both
191  // are supplied.  For efficiency, clients and servers should avoid setting
192  // this redundant value.
193  // Present in both GetUpdatesResponse and CommitMessage.
194  optional string non_unique_name = 8;
195
196  // A value from a monotonically increasing sequence that indicates when
197  // this item was last updated on the server. This is now equivalent
198  // to version. This is now deprecated in favor of version.
199  // Present only in GetUpdatesResponse.
200  optional int64 sync_timestamp = 9;
201
202  // If present, this tag identifies this item as being a uniquely
203  // instanced item.  The server ensures that there is never more
204  // than one entity in a user's store with the same tag value.
205  // This value is used to identify and find e.g. the "Google Chrome" settings
206  // folder without relying on it existing at a particular path, or having
207  // a particular name, in the data store.
208  //
209  // This variant of the tag is created by the server, so clients can't create
210  // an item with a tag using this field.
211  //
212  // Use client_defined_unique_tag if you want to create one from the client.
213  //
214  // An item can't have both a client_defined_unique_tag and
215  // a server_defined_unique_tag.
216  //
217  // Present only in GetUpdatesResponse.
218  optional string server_defined_unique_tag = 10;
219
220  // If this group is present, it implies that this SyncEntity corresponds to
221  // a bookmark or a bookmark folder.
222  //
223  // This group is deprecated; clients should use the bookmark EntitySpecifics
224  // protocol buffer extension instead.
225  optional group BookmarkData = 11 {
226    // We use a required field to differentiate between a bookmark and a
227    // bookmark folder.
228    // Present in both GetUpdatesMessage and CommitMessage.
229    required bool bookmark_folder = 12;
230
231    // For bookmark objects, contains the bookmark's URL.
232    // Present in both GetUpdatesResponse and CommitMessage.
233    optional string bookmark_url = 13;
234
235    // For bookmark objects, contains the bookmark's favicon. The favicon is
236    // represented as a 16X16 PNG image.
237    // Present in both GetUpdatesResponse and CommitMessage.
238    optional bytes bookmark_favicon = 14;
239  }
240
241  // Supplies a numeric position for this item, relative to other items with the
242  // same parent.  Deprecated in M26, though clients are still required to set
243  // it.
244  //
245  // Present in both GetUpdatesResponse and CommitMessage.
246  //
247  // At one point this was used as an alternative / supplement to
248  // the deprecated |insert_after_item_id|, but now it, too, has been
249  // deprecated.
250  //
251  // In order to maintain compatibility with older clients, newer clients should
252  // still set this field.  Its value should be based on the first 8 bytes of
253  // this item's |unique_position|.
254  //
255  // Nerwer clients must also support the receipt of items that contain
256  // |position_in_parent| but no |unique_position|.  They should locally convert
257  // the given int64 position to a UniquePosition.
258  //
259  // The conversion from int64 to UniquePosition is as follows:
260  // The int64 value will have its sign bit flipped then placed in big endian
261  // order as the first 8 bytes of the UniquePosition.  The subsequent bytes of
262  // the UniquePosition will consist of the item's unique suffix.
263  //
264  // Conversion from UniquePosition to int64 reverses this process: the first 8
265  // bytes of the position are to be interpreted as a big endian int64 value
266  // with its sign bit flipped.
267  optional int64 position_in_parent = 15;
268
269  // Contains the ID of the element (under the same parent) after which this
270  // element resides. An empty string indicates that the element is the first
271  // element in the parent.  This value is used during commits to specify
272  // a relative position for a position change.  In the context of
273  // a GetUpdatesMessage, |position_in_parent| is used instead to
274  // communicate position.
275  //
276  // Present only in CommitMessage.
277  //
278  // This is deprecated.  Clients are allowed to omit this as long as they
279  // include |position_in_parent| instead.
280  optional string insert_after_item_id = 16;
281
282  // Arbitrary key/value pairs associated with this item.
283  // Present in both GetUpdatesResponse and CommitMessage.
284  // Deprecated.
285  // optional ExtendedAttributes extended_attributes = 17;
286
287  // If true, indicates that this item has been (or should be) deleted.
288  // Present in both GetUpdatesResponse and CommitMessage.
289  optional bool deleted = 18 [default = false];
290
291  // A GUID that identifies the the sync client who initially committed
292  // this entity.  This value corresponds to |cache_guid| in CommitMessage.
293  // This field, along with |originator_client_item_id|, can be used to
294  // reunite the original with its official committed version in the case
295  // where a client does not receive or process the commit response for
296  // some reason.
297  //
298  // Present only in GetUpdatesResponse.
299  //
300  // This field is also used in determining the unique identifier used in
301  // bookmarks' unique_position field.
302  optional string originator_cache_guid = 19;
303
304  // The local item id of this entry from the client that initially
305  // committed this entity. Typically a negative integer.
306  // Present only in GetUpdatesResponse.
307  //
308  // This field is also used in determinging the unique identifier used in
309  // bookmarks' unique_position field.
310  optional string originator_client_item_id = 20;
311
312  // Extensible container for datatype-specific data.
313  // This became available in version 23 of the protocol.
314  optional EntitySpecifics specifics = 21;
315
316  // Indicate whether this is a folder or not. Available in version 23+.
317  optional bool folder = 22 [default = false];
318
319  // A client defined unique hash for this entity.
320  // Similar to server_defined_unique_tag.
321  //
322  // When initially committing an entity, a client can request that the entity
323  // is unique per that account. To do so, the client should specify a
324  // client_defined_unique_tag. At most one entity per tag value may exist.
325  // per account. The server will enforce uniqueness on this tag
326  // and fail attempts to create duplicates of this tag.
327  // Will be returned in any updates for this entity.
328  //
329  // The difference between server_defined_unique_tag and
330  // client_defined_unique_tag is the creator of the entity. Server defined
331  // tags are entities created by the server at account creation,
332  // while client defined tags are entities created by the client at any time.
333  //
334  // During GetUpdates, a sync entity update will come back with ONE of:
335  // a) Originator and cache id - If client committed the item as non "unique"
336  // b) Server tag - If server committed the item as unique
337  // c) Client tag - If client committed the item as unique
338  //
339  // May be present in CommitMessages for the initial creation of an entity.
340  // If present in Commit updates for the entity, it will be ignored.
341  //
342  // Available in version 24+.
343  //
344  // May be returned in GetUpdatesMessage and sent up in CommitMessage.
345  //
346  optional string client_defined_unique_tag = 23;
347
348  // This positioning system had a relatively short life.  It was made obsolete
349  // by |unique_position| before either the client or server made much of an
350  // attempt to support it.  In fact, no client ever read or set this field.
351  //
352  // Deprecated in M26.
353  optional bytes ordinal_in_parent = 24;
354
355  // This is the fourth attempt at positioning.
356  //
357  // This field is present in both GetUpdatesResponse and CommitMessage, if the
358  // item's type requires it and the client that wrote the item supports it (M26
359  // or higher).  Clients must also be prepared to handle updates from clients
360  // that do not set this field.  See the comments on
361  // |server_position_in_parent| for more information on how this is handled.
362  //
363  // This field will not be set for items whose type ignores positioning.
364  // Clients should not attempt to read this field on the receipt of an item of
365  // a type that ignores positioning.
366  //
367  // Refer to its definition in unique_position.proto for more information about
368  // its internal representation.
369  optional UniquePosition unique_position = 25;
370
371  // Attachment ids of attachments associated with this SyncEntity.
372  repeated AttachmentIdProto attachment_id = 26;
373};
374
375// This message contains diagnostic information used to correlate
376// commit-related traffic with extensions-related mutations to the
377// data models in chromium.  It plays no functional role in
378// processing this CommitMessage.
379message ChromiumExtensionsActivity {
380  // The human-readable ID identifying the extension responsible
381  // for the traffic reported in this ChromiumExtensionsActivity.
382  optional string extension_id = 1;
383
384  // How many times the extension successfully invoked a write
385  // operation through the bookmarks API since the last CommitMessage.
386  optional uint32 bookmark_writes_since_last_commit = 2;
387};
388
389// Client specific configuration information.
390message ClientConfigParams {
391  // The set of data types this client has enabled. Note that this does not
392  // include proxy types, as they do not have protocol field numbers and are
393  // placeholder types that implicitly enable protocol types.
394 repeated int32 enabled_type_ids = 1;
395
396 // Whether the PROXY_TABS proxy datatype is enabled on this client.
397 optional bool tabs_datatype_enabled = 2;
398};
399
400message CommitMessage {
401  repeated SyncEntity entries = 1;
402
403  // A GUID that identifies the committing sync client.  This value will be
404  // returned as originator_cache_guid for any new items.
405  optional string cache_guid = 2;
406
407  repeated ChromiumExtensionsActivity extensions_activity = 3;
408
409  // The configuration of this client at commit time. Used by the server to
410  // make commit-time decisions about how to process datatypes that might
411  // involve server-side interaction, and e.g require explicit user intent for
412  // syncing a particular data type regardless of whether a commit for that
413  // datatype is currently being sent up.
414  optional ClientConfigParams config_params = 4;
415
416  // Set of optional per-client datatype contexts.
417  repeated DataTypeContext client_contexts = 5;
418};
419
420// This message communicates additional per-type information related to
421// requests with origin GU_TRIGGER.  This message is not relevant when any
422// other origin value is used.
423// Introduced in M29.
424message GetUpdateTriggers {
425  // An opaque-to-the-client string of bytes, received through a notification,
426  // that the server may interpret as a hint about the location of the latest
427  // version of the data for this type.
428  //
429  // Note that this will eventually replace the 'optional' field of the same
430  // name defined in the progress marker, but the client and server should
431  // support both until it's safe to deprecate the old one.
432  //
433  // This field was introduced in M29.
434  repeated string notification_hint = 1;
435
436  // This flag is set if the client was forced to drop hints because the number
437  // of queued hints exceeded its limit.  The oldest hints will be discarded
438  // first.  Introduced in M29.
439  optional bool client_dropped_hints = 2;
440
441  // This flag is set when the client suspects that its list of invalidation
442  // hints may be incomplete.  This may be the case if:
443  // - The client is syncing for the first time.
444  // - The client has just restarted and it was unable to keep track of
445  //   invalidations that were received prior to the restart.
446  // - The client's connection to the invalidation server is currently or
447  //   was recently broken.
448  //
449  // It's difficult to provide more details here.  This is implemented by
450  // setting the flag to false whenever anything that might adversely affect
451  // notifications happens (eg. a crash, restart on a platform that doesn't
452  // support invalidation ack-tracking, transient invalidation error) and is
453  // unset only after we've experienced one successful sync cycle while
454  // notifications were enabled.
455  //
456  // This flag was introduced in M29.
457  optional bool invalidations_out_of_sync = 3;
458
459  // This counts the number of times the syncer has been asked to commit
460  // changes for this type since the last successful sync cycle.  The number of
461  // nudges may not be related to the actual number of items modified.  It
462  // often correlates with the number of user actions, but that's not always
463  // the case.
464  // Introduced in M29.
465  optional int64 local_modification_nudges = 4;
466
467  // This counts the number of times the syncer has been explicitly asked to
468  // fetch updates for this type since the last successful sync cycle.  These
469  // explicit refresh requests should be relatively rare on most platforms, and
470  // associated with user actions.  For example, at the time of this writing
471  // the most common (only?) source of refresh requests is when a user opens
472  // the new tab page on a platform that does not support sessions
473  // invalidations.
474  // Introduced in M29.
475  optional int64 datatype_refresh_nudges = 5;
476
477  // This flag is set if the invalidation server reports that it may have
478  // dropped some invalidations at some point.  Introduced in M33.
479  optional bool server_dropped_hints = 6;
480
481  // This flag is set if this GetUpdate request is due at least in part due
482  // to the fact that this type has not finished initial sync yet, and the
483  // client would like to initialize itself with the server data.
484  //
485  // Only some types support performing an initial sync as part of a normal
486  // GetUpdate request.  Many types must be in configure mode when fetching
487  // initial sync data.
488  //
489  // Introduced in M38.
490  optional bool initial_sync_in_progress = 7;
491}
492
493message GarbageCollectionDirective {
494  enum Type {
495    UNKNOWN = 0;
496    VERSION_WATERMARK = 1;
497    AGE_WATERMARK = 2;
498    MAX_ITEM_COUNT = 3;
499  }
500
501  optional Type type = 1 [default = UNKNOWN];
502
503  // This field specifies the watermark for the versions which should get
504  // garbage collected.  The client should purge all sync entities with a
505  // version smaller than version_watermark locally.
506  optional int64 version_watermark = 2;
507
508  // This field specifies the watermark in terms of age in days.  The client
509  // should purge all sync entities which are older than this specific value
510  // based on last modified time.
511  optional int32 age_watermark_in_days = 3;
512
513  // This field specifies the max number of items that the client should keep
514  // for a specific datatype.  If the number of items exceeds this limit, the
515  // client should purge the extra sync entities based on the LRU rule.
516  optional int32 max_number_of_items = 4;
517}
518
519message DataTypeProgressMarker {
520  // An integer identifying the data type whose progress is tracked by this
521  // marker.  The legitimate values of this field correspond to the protobuf
522  // field numbers of all EntitySpecifics fields supported by the server.
523  // These values are externally declared in per-datatype .proto files.
524  optional int32 data_type_id = 1;
525
526  // An opaque-to-the-client sequence of bytes that the server may interpret
527  // as an indicator of the client's knowledge state.  If this is empty or
528  // omitted by the client, it indicates that the client is initiating a
529  // a first-time sync of this datatype.  Otherwise, clients must supply a
530  // value previously returned by the server in an earlier GetUpdatesResponse.
531  // These values are not comparable or generable on the client.
532  //
533  // The opaque semantics of this field are to afford server implementations
534  // some flexibility in implementing progress tracking.  For instance,
535  // a server implementation built on top of a distributed storage service --
536  // or multiple heterogenous such services -- might need to supply a vector
537  // of totally ordered monotonic update timestamps, rather than a single
538  // monotonically increasing value.  Other optimizations may also be
539  // possible if the server is allowed to embed arbitrary information in
540  // the progress token.
541  //
542  // Server implementations should keep the size of these tokens relatively
543  // small, on the order of tens of bytes, and they should remain small
544  // regardless of the number of items synchronized.  (A possible bad server
545  // implementation would be for progress_token to contain a list of all the
546  // items ever sent to the client.  Servers shouldn't do this.)
547  optional bytes token = 2;
548
549  // Clients that previously downloaded updates synced using the timestamp based
550  // progress tracking mechanism, but which wish to switch over to the opaque
551  // token mechanism can set this field in a GetUpdatesMessage.  The server
552  // will perform a get updates operation as normal from the indicated
553  // timestamp, and return only an opaque progress token.
554  optional int64 timestamp_token_for_migration = 3;
555
556  // An opaque-to-the-client string of bytes, received through a notification,
557  // that the server may interpret as a hint about the location of the latest
558  // version of the data for this type.
559  //
560  // Deprecated in M29.  We should use the repeated field version in the
561  // PerClientTypeState instead.
562  optional string notification_hint = 4;
563
564  // This field will be included only in GetUpdates with origin GU_TRIGGER.
565  optional GetUpdateTriggers get_update_triggers = 5;
566
567  // The garbage collection directive for this data type.  The client should
568  // purge items locally based on this directive.  Since this directive is
569  // designed to be sent from server only, the client should persist it locally
570  // as needed and avoid sending it to the server.
571  optional GarbageCollectionDirective gc_directive = 6;
572}
573
574message GetUpdatesMessage {
575  // Indicates the client's current progress in downloading updates.  A
576  // from_timestamp value of zero means that the client is requesting a first-
577  // time sync.  After that point, clients should fill in this value with the
578  // value returned in the last-seen GetUpdatesResponse.new_timestamp.
579  //
580  // from_timestamp has been deprecated; clients should use
581  // |from_progress_marker| instead, which allows more flexibility.
582  optional int64 from_timestamp = 1;
583
584  // Indicates the reason for the GetUpdatesMessage.
585  // Deprecated in M29.  We should eventually rely on GetUpdatesOrigin instead.
586  // Newer clients will support both systems during the transition period.
587  optional GetUpdatesCallerInfo caller_info = 2;
588
589  // Indicates whether related folders should be fetched.
590  optional bool fetch_folders = 3 [default = true];
591
592  // The presence of an individual EntitySpecifics field indicates that the
593  // client requests sync object types associated with that field.  This
594  // determination depends only on the presence of the field, not its
595  // contents -- thus clients should send empty messages as the field value.
596  // For backwards compatibility only bookmark objects will be sent to the
597  // client should requested_types not be present.
598  //
599  // requested_types may contain multiple EntitySpecifics fields -- in this
600  // event, the server will return items of all the indicated types.
601  //
602  // requested_types has been deprecated; clients should use
603  // |from_progress_marker| instead, which allows more flexibility.
604  optional EntitySpecifics requested_types = 4;
605
606  // Client-requested limit on the maximum number of updates to return at once.
607  // The server may opt to return fewer updates than this amount, but it should
608  // not return more.
609  optional int32 batch_size = 5;
610
611  // Per-datatype progress marker.  If present, the server will ignore
612  // the values of requested_types and from_timestamp, using this instead.
613  //
614  // With the exception of certain configuration or initial sync requests, the
615  // client should include one instance of this field for each enabled data
616  // type.
617  repeated DataTypeProgressMarker from_progress_marker = 6;
618
619  // Indicates whether the response should be sent in chunks.  This may be
620  // needed for devices with limited memory resources.  If true, the response
621  // will include one or more ClientToServerResponses, with the frist one
622  // containing GetUpdatesMetadataResponse, and the remaining ones, if any,
623  // containing GetUpdatesStreamingResponse.  These ClientToServerResponses are
624  // delimited by a length prefix, which is encoded as a varint.
625  optional bool streaming = 7 [default = false];
626
627  // Whether the client needs the server to provide an encryption key for this
628  // account.
629  // Note: this should typically only be set on the first GetUpdates a client
630  // requests. Clients are expected to persist the encryption key from then on.
631  // The allowed frequency for requesting encryption keys is much lower than
632  // other datatypes, so repeated usage will likely result in throttling.
633  optional bool need_encryption_key = 8 [default = false];
634
635  // Whether to create the mobile bookmarks folder if it's not
636  // already created.  Should be set to true only by mobile clients.
637  optional bool create_mobile_bookmarks_folder = 1000 [default = false];
638
639  // This value is an updated version of the GetUpdatesCallerInfo's
640  // GetUpdatesSource.  It describes the reason for the GetUpdate request.
641  // Introduced in M29.
642  optional SyncEnums.GetUpdatesOrigin get_updates_origin = 9;
643
644  // Whether this GU also serves as a retry GU. Any GU that happens after
645  // retry timer timeout is a retry GU effectively.
646  optional bool is_retry = 10 [default = false];
647
648  // Set of optional per-client datatype contexts.
649  repeated DataTypeContext client_contexts = 11;
650};
651
652message AuthenticateMessage {
653  required string auth_token = 1;
654};
655
656message ClearUserDataMessage {
657};
658
659message ClearUserDataResponse {
660};
661
662// The client must preserve, store, and resend the chip bag with
663// every request.  The server depends on the chip bag in order
664// to precisely choreograph a client-server state machines.
665//
666// Because the client stores and sends this data on every request,
667// the contents of the chip bag should be kept relatively small.
668//
669// If the server does not return a chip bag, the client must assume
670// that there has been no change to the chip bag.  The client must
671// resend the bag of chips it had prior on the next request.
672//
673// The client must make the chip bag durable if and only if it
674// processes the response from the server.
675message ChipBag {
676  // Server chips are deliberately oqaque, allowing the server
677  // to encapsulate its state machine logic.
678  optional bytes server_chips = 1;
679}
680
681// Information about the syncer's state.
682message ClientStatus {
683  // Flag to indicate if the client has detected hierarchy conflcits.  The flag
684  // is left unset if update application has not been attempted yet.
685  //
686  // The server should attempt to resolve any hierarchy conflicts when this flag
687  // is set.  The client may not assume that any particular action will be
688  // taken.  There is no guarantee the problem will be addressed in a reasonable
689  // amount of time.
690  optional bool hierarchy_conflict_detected = 1;
691}
692
693// A single datatype's sync context. Allows the datatype to pass along
694// datatype specific information with its own server backend.
695message DataTypeContext {
696  // The type this context is associated with.
697  optional int32 data_type_id = 1;
698  // The context for the datatype.
699  optional bytes context = 2;
700  // The version of the context.
701  optional int64 version = 3;
702}
703
704message ClientToServerMessage {
705  required string share = 1;
706  optional int32 protocol_version = 2 [default = 34];
707  enum Contents {
708    COMMIT = 1;
709    GET_UPDATES = 2;
710    AUTHENTICATE = 3;
711    CLEAR_DATA = 4;
712  }
713
714  required Contents message_contents = 3;
715  optional CommitMessage commit = 4;
716  optional GetUpdatesMessage get_updates = 5;
717  optional AuthenticateMessage authenticate = 6;
718
719  // Request to clear all Chromium data from the server.
720  optional ClearUserDataMessage clear_user_data = 9;
721
722  optional string store_birthday = 7; // Opaque store ID; if it changes, duck!
723  // The client sets this if it detects a sync issue. The server will tell it
724  // if it should perform a refresh.
725  optional bool sync_problem_detected = 8 [default = false];
726
727  // Client side state information for debugging purpose.
728  // This is only sent on the first getupdates of every sync cycle,
729  // as an optimization to save bandwidth.
730  optional DebugInfo debug_info = 10;
731
732  // Per-client state for use by the server. Sent with every message sent to the
733  // server.
734  optional ChipBag bag_of_chips = 11;
735
736  // Google API key.
737  optional string api_key = 12;
738
739  // Client's self-reported state.
740  // The client should set this on every message sent to the server, though its
741  // member fields may often be unset.
742  optional ClientStatus client_status = 13;
743
744  // The ID that our invalidation client used to identify itself to the server.
745  // Sending the ID here allows the server to not send notifications of our own
746  // changes to our invalidator.
747  optional string invalidator_client_id = 14;
748};
749
750// This request allows the client to convert a specific crash identifier
751// into more general information (e.g. hash of the crashing call stack)
752// suitable for upload in an (authenticated) DebugInfo event.
753message GetCrashInfoRequest {
754  // Id of the uploaded crash.
755  optional string crash_id = 1;
756
757  // Time that the crash occurred.
758  optional int64 crash_time_millis = 2;
759}
760
761// Proto to be written in its entirety to the debug info log.
762message GetCrashInfoResponse {
763  // Hash of the crashing call stack.
764  optional string stack_id = 1;
765
766  // Time of the crash, potentially rounded to remove
767  // significant bits.
768  optional int64 crash_time_millis = 2;
769}
770
771message CommitResponse {
772  enum ResponseType {
773    SUCCESS = 1;
774    CONFLICT = 2; // You're out of date; update and check your data
775    // TODO(ncarter): What's the difference between RETRY and TRANSIENT_ERROR?
776    RETRY = 3; // Someone has a conflicting, non-expired session open
777    INVALID_MESSAGE = 4; // What the client sent was invalid, and trying again
778                         // won't help.
779    OVER_QUOTA = 5; // This operation would put you, or you are, over quota
780    TRANSIENT_ERROR = 6; // Something went wrong; try again in a bit
781  }
782  repeated group EntryResponse = 1 {
783    required ResponseType response_type = 2;
784
785    // Sync servers may also return a new ID for an existing item, indicating
786    // a new entry's been created to hold the data the client's sending up.
787    optional string id_string = 3;
788
789    // should be filled if our parent was assigned a new ID.
790    optional string parent_id_string = 4;
791
792    // This value is the same as the position_in_parent value returned within
793    // the SyncEntity message in GetUpdatesResponse.  There was a time when the
794    // client would attempt to honor this position, but nowadays the server
795    // should ensure it is no different from the position_in_parent sent up in
796    // the commit request and the client should not read it.
797    optional int64 position_in_parent = 5;
798
799    // The item's current version.
800    optional int64 version = 6;
801
802    // Allows the server to move-aside an entry as it's being committed.
803    // This name is the same as the name field returned within the SyncEntity
804    // message in GetUpdatesResponse.
805    optional string name = 7;
806
807    // This name is the same as the non_unique_name field returned within the
808    // SyncEntity message in GetUpdatesResponse.
809    optional string non_unique_name = 8;
810
811    optional string error_message = 9;
812
813    // Last modification time (in java time milliseconds).  Allows the server
814    // to override the client-supplied mtime during a commit operation.
815    optional int64 mtime = 10;
816  }
817};
818
819message GetUpdatesResponse {
820  // New sync entries that the client should apply.
821  repeated SyncEntity entries = 1;
822
823  // If there are more changes on the server that weren't processed during this
824  // GetUpdates request, the client should send another GetUpdates request and
825  // use new_timestamp as the from_timestamp value within GetUpdatesMessage.
826  //
827  // This field has been deprecated and will be returned only to clients
828  // that set the also-deprecated |from_timestamp| field in the update request.
829  // Clients should use |from_progress_marker| and |new_progress_marker|
830  // instead.
831  optional int64 new_timestamp = 2;
832
833  // DEPRECATED FIELD - server does not set this anymore.
834  optional int64 deprecated_newest_timestamp = 3;
835
836  // Approximate count of changes remaining - use this for UI feedback.
837  // If present and zero, this estimate is firm: the server has no changes
838  // after the current batch.
839  optional int64 changes_remaining = 4;
840
841  // Opaque, per-datatype timestamp-like tokens.  A client should use this
842  // field in lieu of new_timestamp, which is deprecated in newer versions
843  // of the protocol.  Clients should retain and persist the values returned
844  // in this field, and present them back to the server to indicate the
845  // starting point for future update requests.
846  //
847  // This will be sent only if the client provided |from_progress_marker|
848  // in the update request.
849  //
850  // The server may provide a new progress marker even if this is the end of
851  // the batch, or if there were no new updates on the server; and the client
852  // must save these.  If the server does not provide a |new_progress_marker|
853  // value for a particular datatype, when the request provided a
854  // |from_progress_marker| value for that datatype, the client should
855  // interpret this to mean "no change from the previous state" and retain its
856  // previous progress-marker value for that datatype.
857  //
858  // Progress markers in the context of a response will never have the
859  // |timestamp_token_for_migration| field set.
860  repeated DataTypeProgressMarker new_progress_marker = 5;
861
862  // The current encryption keys associated with this account. Will be set if
863  // the GetUpdatesMessage in the request had need_encryption_key == true or
864  // the server has updated the set of encryption keys (e.g. due to a key
865  // rotation).
866  repeated bytes encryption_keys = 6;
867
868  // Set of optional datatype contexts server mutations.
869  repeated DataTypeContext context_mutations = 7;
870};
871
872// The metadata response for GetUpdatesMessage.  This response is sent when
873// streaming is set to true in the request.  It is prefixed with a length
874// delimiter, which is encoded in varint.
875message GetUpdatesMetadataResponse {
876  // Approximate count of changes remaining.  Detailed comment is available in
877  // GetUpdatesResponse.
878  optional int64 changes_remaining = 1;
879
880  // Opaque, per-datatype timestamp-like tokens.  Detailed comment is available
881  // in GetUpdatesResponse.
882  repeated DataTypeProgressMarker new_progress_marker = 2;
883};
884
885// The streaming response message for GetUpdatesMessage.  This message is sent
886// when streaming is set to true in the request.  There may be multiple
887// GetUpdatesStreamingResponse messages in a response.  This type of messages
888// is preceded by GetUpdatesMetadataResponse.  It is prefixed with a length
889// delimiter, which is encoded in varint.
890message GetUpdatesStreamingResponse {
891  // New sync entries that the client should apply.
892  repeated SyncEntity entries = 1;
893};
894
895// A user-identifying struct.  For a given Google account the email and display
896// name can change, but obfuscated_id should be constant.
897// The obfuscated id is optional because at least one planned use of the proto
898// (sharing) does not require it.
899message UserIdentification {
900  required string email = 1;  // the user's full primary email address.
901  optional string display_name = 2;  // the user's display name.
902  optional string obfuscated_id = 3;  // an obfuscated, opaque user id.
903};
904
905message AuthenticateResponse {
906  // Optional only for backward compatibility.
907  optional UserIdentification user = 1;
908};
909
910message ThrottleParameters {
911  // Deprecated. Remove this from the server side.
912  required int32 min_measure_payload_size = 1;
913  required double target_utilization = 2;
914  required double measure_interval_max = 3;
915  required double measure_interval_min = 4;
916  required double observation_window = 5;
917};
918
919message ClientToServerResponse {
920  optional CommitResponse commit = 1;
921  optional GetUpdatesResponse get_updates = 2;
922  optional AuthenticateResponse authenticate = 3;
923
924  // Up until protocol_version 24, the default was SUCCESS which made it
925  // impossible to add new enum values since older clients would parse any
926  // out-of-range value as SUCCESS. Starting with 25, unless explicitly set,
927  // the error_code will be UNKNOWN so that clients know when they're
928  // out-of-date. Note also that when using protocol_version < 25,
929  // TRANSIENT_ERROR is not supported. Instead, the server sends back a HTTP
930  // 400 error code. This is deprecated now.
931  optional SyncEnums.ErrorType error_code = 4 [default = UNKNOWN];
932  optional string error_message = 5;
933
934  // Opaque store ID; if it changes, the contents of the client's cache
935  // is meaningless to this server.  This happens most typically when
936  // you switch from one storage backend instance (say, a test instance)
937  // to another (say, the official instance).
938  optional string store_birthday = 6;
939
940  optional ClientCommand client_command = 7;
941  optional ProfilingData profiling_data = 8;
942  optional ClearUserDataResponse clear_user_data = 9;
943  optional GetUpdatesMetadataResponse stream_metadata = 10;
944  // If GetUpdatesStreamingResponse is contained in the ClientToServerResponse,
945  // none of the other fields (error_code and etc) will be set.
946  optional GetUpdatesStreamingResponse stream_data = 11;
947
948  // The data types whose storage has been migrated.  Present when the value of
949  // error_code is MIGRATION_DONE.
950  repeated int32 migrated_data_type_id = 12;
951
952  message Error {
953    optional SyncEnums.ErrorType error_type = 1 [default = UNKNOWN];
954    optional string error_description       = 2;
955    optional string url                     = 3;
956    optional SyncEnums.Action action        = 4 [default = UNKNOWN_ACTION];
957
958    // Currently only meaningful if |error_type| is throttled. If this field
959    // is absent then the whole client (all datatypes) is throttled.
960    repeated int32 error_data_type_ids = 5;
961  }
962  optional Error error = 13;
963
964  // The new per-client state for this client. If set, should be persisted and
965  // sent with any subsequent ClientToServerMessages.
966  optional ChipBag new_bag_of_chips = 14;
967};
968