tree: c593fe49c462a93c180f053a2abaa57d0b3b0333 [path history] [tgz]
  1. app_list_specifics.proto
  2. app_notification_specifics.proto
  3. app_setting_specifics.proto
  4. app_specifics.proto
  5. arc_package_specifics.proto
  6. autofill_offer_specifics.proto
  7. autofill_specifics.proto
  8. autofill_wallet_usage_specifics.proto
  9. bookmark_model_metadata.proto
  10. bookmark_specifics.proto
  11. BUILD.gn
  12. client_commands.proto
  13. client_debug_info.proto
  14. contact_info_specifics.proto
  15. data_type_progress_marker.proto
  16. DEPS
  17. device_info_specifics.proto
  18. dictionary_specifics.proto
  19. encryption.proto
  20. entity_data.cc
  21. entity_data.h
  22. entity_data_unittest.cc
  23. entity_metadata.proto
  24. entity_specifics.proto
  25. experiment_status.proto
  26. experiments_specifics.proto
  27. extension_setting_specifics.proto
  28. extension_specifics.proto
  29. favicon_image_specifics.proto
  30. favicon_tracking_specifics.proto
  31. gaia_password_reuse.proto
  32. get_updates_caller_info.proto
  33. history_delete_directive_specifics.proto
  34. history_specifics.proto
  35. history_status.proto
  36. local_trusted_vault.proto
  37. loopback_server.proto
  38. managed_user_setting_specifics.proto
  39. managed_user_shared_setting_specifics.proto
  40. managed_user_specifics.proto
  41. model_type_state.proto
  42. model_type_store_schema_descriptor.proto
  43. nigori_local_data.proto
  44. nigori_specifics.proto
  45. os_preference_specifics.proto
  46. os_priority_preference_specifics.proto
  47. OWNERS
  48. password_specifics.proto
  49. persisted_entity_data.proto
  50. preference_specifics.proto
  51. printer_specifics.proto
  52. printers_authorization_server_specifics.proto
  53. priority_preference_specifics.proto
  54. proto_enum_conversions.cc
  55. proto_enum_conversions.h
  56. proto_enum_conversions_unittest.cc
  57. proto_memory_estimations.cc
  58. proto_memory_estimations.h
  59. proto_value_conversions.cc
  60. proto_value_conversions.h
  61. proto_value_conversions_unittest.cc
  62. proto_visitors.h
  63. protocol_sources.gni
  64. reading_list_specifics.proto
  65. README.md
  66. saved_tab_group_specifics.proto
  67. search_engine_specifics.proto
  68. security_event_specifics.proto
  69. send_tab_to_self_specifics.proto
  70. session_specifics.proto
  71. sharing_message_specifics.proto
  72. sync.proto
  73. sync_entity.proto
  74. sync_enums.proto
  75. sync_invalidations_payload.proto
  76. sync_protocol_error.cc
  77. sync_protocol_error.h
  78. synced_notification_app_info_specifics.proto
  79. synced_notification_specifics.proto
  80. test.proto
  81. theme_specifics.proto
  82. typed_url_specifics.proto
  83. unique_position.proto
  84. user_consent_specifics.proto
  85. user_consent_types.proto
  86. user_event_specifics.proto
  87. vault.proto
  88. web_app_specifics.proto
  89. webauthn_credential_specifics.proto
  90. wifi_configuration_specifics.proto
  91. workspace_desk_specifics.proto
components/sync/protocol/README.md

Sync Protocol Style

General guidelines:

  • Follow the Protocol Buffers Style Guide
  • Follow the Proto Do‘s and Don’ts (sorry, Googlers only).
  • Maintain local consistency.
  • Use proto2 syntax.
  • Always get a review from someone in the OWNERS file in this folder. Don't use owners from higher-level folders, and never TBR changes!

Some specific guidelines on top of the general ones above, or just things that often come up:

  • Enum entries should be in ALL_CAPS (different from C++!), and for new code, the first entry should be a FOO_UNSPECIFIED = 0 one.
  • Timestamp fields must specify their epoch and unit in a suffix, in this format: _[unix|windows]_epoch_[seconds|millis|micros|nanos], e.g creation_time_unix_epoch_millis.
    • Many existing fields do not follow this format, and specify epoch/unit in a comment instead. Follow the format for all new fields, though!
  • Similarly, duration fields must specify their unit as _[minutes|seconds|millis|...].
  • Proto changes also require corresponding changes in proto_visitors.h and (where appropriate) in proto_enum_conversions.h/cc.
  • Backwards compatibility: In general, all changes must be fully backwards-compatible - consider that a single user might be running different versions of the browser simultaneously! Also note that Sync supports clients up to a few years old, so deprecating/removing an existing field is typically a multi-year process.
    • As one special case, renaming a field within a specifics message is generally safe (unless there are special server-side integrations that depend on the name). However, never rename fields anywhere outside of specifics.
  • Deprecating fields:
    • If the field is still accessed: Mark it as [deprecated = true]. This is the common case, since the browser typically needs to continue supporting the old field for backwards compatibility reasons.
    • If the field is not accessed anymore (i.e. no non-ancient clients depend on the field being populated anymore, all migration code has been retired, etc): Remove the field, and add reserved entries for both its name and its tag number.
  • Deprecating enum values: This is particularly tricky, especially if the default value is not a FOO_UNSPECIFIED one (see above). A common pattern is prepending DEPRECATED_ to the entry name.