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