Comment #6 on issue 29905 by n...@chromium.org: Support per-datatype
GetUpdates
http://code.google.com/p/chromium/issues/detail?id=29905
In Bug 29836, we came to the decision that a mime type on the SyncEntity
would be
redundant -- the type can be inferred from the object properties, in
particular the
presence of various EntitySpecifics extensions. I agree that there's not
too much
sense in adding the mime-type string to the protocol.
But it looks like we definitely will need to add a "supported object types"
indicator
to GetUpdatesRequest. The possible ideas are:
Most straightforward would be to add a datatype enum { FOLDERS, BOOKMARKS,
CHROMIUM_PREFS, AUTOFILL, ... } and have a repeated field of this enum type
in the
GetUpdatesMessage. When this field is not present, the server would assume
the
default value of [FOLDERS, BOOKMARKS] for backwards compatibility.
A slightly more complex alternative would be to add a single non-repeated
EntitySpecifics field to the GetUpdatesMessage, and use the presence of
multiple
empty-but-present extension messages to indicate that these were supported
types. The
main advantage here is that sync.proto does not have to enumerate every
datatype
explicitly. One tricky thing is how to handle folders, which currently
don't have an
EntitySpecifics extension associated with them -- adding an "is folder"
additional bit
would be a nonorthogonal, so we may want to add a datatype extension to
encapsulate
the top-level Chrome folders.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
